[e2e] Port numbers in the network layer?

[John Day]

At 10:13 AM -0700 5/2/13, Joe Touch wrote:
>Hi, John,
>
>On 5/2/2013 6:22 AM, John Day wrote:
>>Sorry, I got a bit busy and then this got lost on my desktop.
>...
>>>If you want to go that far off the map, connection-id would be needed
>>>only if that multipoint link supported different connections, either
>>>concurrently or in series.
>>
>>No, one does not need to go as far as multipoint links.
>
>Agreed; I mistyped; I meant "only if that point-to-point link".

Right.

>
>>All that is
>>needed are multiple applications trying to use the same media on a
>>point-to-point link.  In that case, a connection-id or flow-id is
>>required; however, addresses are not required.  It is true, that if it
>>is a multi-drop or multi-point link, then addresses are required.
>>Basically, addresses are necessary, if 'the wire" ;-) has more than 2
>>ends! as wireless clearly does.
>
>Wireless includes point-to-point links, in which the information is 
>either collimated (e.g., space-based laser links) or otherwise 
>restricted within the link layer (e.g., CDMA).

Indeed, wireless can be point-to-point as well.

>
>But I think we now agree - connection ID is a connection 
>demultiplexer within a context. It is required only if there is more 
>than one connection to a given endpoint. An endpoint ID is an 
>endpoint demultiplexer, and it is required only if there is more 
>than one receiver on a link.

Excellent.

>
>>>>Strictly speaking, the proper way to define connection-id is the
>>>>concatenation of the port-ids to form a connection-id that is unique
>>>>within the scope of the pair of source/destination addresses.
>>>
>>>Your definition implies that a connection ID differentiates
>>>connections only within one pair of source/destination addresses. That
>>>definition precludes connections that span multiple addresses, e.g.,
>>>striping, or those that can shift addresses.
>>
>>Not in the least, owing to the distinctions noted earlier in this
>>thread, so-called striping and changing addresses are handled quite
>>elegantly.
>
>In order to stripe connections or shift them across links or 
>endpoints within a link, a connection ID needs to be 
>context-independent, i.e., unique across the potentially shared 
>uses. That's a distinct feature of some, but not all, connection IDs.

Alas, but you are right.  The constraints of software are 
sufficiently weak that unlike those of physics which are more 
constraining, it is still often possible to do it wrong.

>
>>>>Given that IP is in a different layer than TCP that would seem to be the
>>>>definition that is consistent with that construction.
>>>
>>>The TCP header includes the IP pseudoheader - notably for the purpose
>>>of connection identification. So TCP is already inconsistent with your
>>>proposed definition (it includes addresses in its connection ID, not
>>>merely as context for its connection ID), and consistent with the way
>>>I already described connections.
>>
>>Actually not.  That is one of the more interesting aspects.
>>
>>The argument for the pseudoheader has always been a bit shaky.  No other
>>Transport Protocol except UDP either within or outside the IETF found
>>the need for it.  There have been many discussions about removing it,
>>but as you know tradition has always won out.
>
>The pseudoheader is an artifact of the TCP/IP split, which isn't as 
>clean as often claimed.
>
>It is used in other transport protocols built on IP, e.g., DCCP and SCTP.
>
>It is not a matter of tradition; it is deeply entrenched with the 
>notion of endpoint and that this notion exists at two different 
>layers that share at least some of the context (IP addresses).

"Deeply entrenched," indeed. (Some would say a synonym for 
tradition.) Strongly reasoned, less so.  As recently described by its 
author, it is this binding that thwarts mobility.

Indeed this "notion" exists in two different layers. In fact, it is a 
general property of all layers.  But I fail to see how that is an 
argument to require a pseudo-header.

>
>>But putting that aside, separating IP from TCP caused more problems than
>>it solved.  Frankly, looking at the range of experience with this class
>>of protocols and a careful analysis of their structure indicates TCP was
>>split in the wrong direction.  It would be much more productive to
>>separate it along lines of control and data. i.e. data transfer and
>>feedback control.  Then UDP is simply a degenerate case.
>
>I'm not sure why you consider TCP not to have separate control and 
>data, but if it's not distinct enough, consider the other protocols 
>cited above.

It is far from distinct.  The two are tightly bound by header if 
nothing else.  Yes, most other protocols have not adopted that 
approach.  But the coupling between the two is very very loose.

>
>>>>According to this socket pair definition then, is the connection id a
>>>>Network Layer identifier or a Transport Layer identifier?
>>>
>>>Transport layer ID that is based on a transport header that subsumes a
>>>subset of the network header.
>>
>>Huh?  Next you are going to tell me that it is "small, green and split
>>three ways"!  ;-)
>
>The transport layer flow is *defined* as the socket pair, which is 
>defined in TCP (and used in other Internet transports) as combining 
>the transport header context (port pair) with the IP context (IP 
>address pair), the latter of which is part of the pseudoheader for 
>that reason.

I realize this is the definition, and I would even agree with 
including the same error-check-code, if they were in the same layer. 
But since it is said they aren't, I fail to see the need and I 
definitely see the constraints.

Is there some condition in which a router might put a TCP packet on a 
different IP packet?  The only reason I can see for having it.

>
>>It is also worth noting that it is important that for security reasons,
>>that identifiers shared between layers not be carried in protocol and
>>that identifiers used by a protocol machine to distinguish flows be
>>identifiers it created.
>
>If the IDs are not carried within the messages, how are multiplexed 
>messages to be demultiplexed?

This was previously covered.

>
>>>>>>>     - an identifier for the upper layer protocol (service)
>>>>>>>     (the dest port, in all UDP packets or in the TCP SYN)
>>>>>>
>>>>>>Actually, it does not identify the upper protocol or application,
>>>>>>but a
>>>>>>path to the upper protocol or application.  It is significant that
>>>>>>this
>>>>>>identified the type but there was no means (unless application
>>>>>>specific)
>>>>>>to establish communication with a particular instance of an
>>>>>>application.
>>>>>
>>>>>No protocol has a "means" to initiate connection with anything that
>>>>>isn't waiting for it on the other end. In this case, it would be an
>>>>>application listening on the socket. The assumption is both that the
>>>>>application is listening AND that the service (application protocol)
>>>>>is as expected.
>>>>
>>>>Do you mean the something has to be listening before the requesting
>>>>application initiates the connection?  In that case, it is not true. It
>>>>is possible to do and there are protocols operating today that do it.
>>>>Admittedly, they are not Internet protocols but that doesn't matter.
>>>
>>>Something has to listen in order for communication to proceed. That
>>>event need not precede the request to initiate from the other end, but
>>>it does precede the connection.
>>
>>I tried to be careful in how I worded that.  It is true that something
>>must respond to a request for connection and create a binding between
>>the requested application and the flow that may be created.  There is
>>not necessary for the application to have done anything.
>
>In the context of a transport protocol, the layer above that 
>interacts with the protocol to create flows, respond to them, and 
>send/receive messages is defined as the "application". That may or 
>may not be L7.

There is no L7 or L6.  Those were fictions that were dispensed with in 1983.

>...
>>>>For example, I might want a
>>>>different one for different security domains or something like that.  So
>>>>why not have a few hundred of the same protocol?
>>>
>>>It's a protocol-type, not a protocol-ID; types to not typically
>>>indicate instances. If you want an instance ID at that layer (i.e.,
>>>within IP to demux different TCP instances rather than connections
>>>within one instance) you would need another field for that purpose.
>>
>>Ahhh, so the "protocol-id" field in IP is not a protocol-id field.
>>Actually, that was my point.
>
>That depends on your parsing of "-id".
>
>I think you interpret "protocol-id" as meaning 
>"protocol-instance-identifier", where the more common interpretation 
>(AFAICT) is "protocol-type-identifier".
>
>That's because we don't typically have current cases with multiple 
>instances of a single protocol. We have flows, but that's a 
>different thing. There could be multiple protocol instances each 
>with multiple flows.
>
>So I interpret "protocol-id" as I think most people do.

Excellent. That was my point.  The field has the wrong name.

>
>>Given how it is used, it can't be a protocol-id field.
>
>It can't be a protocol instance field. But you haven't explained why 
>this is important or useful. That's a separate thread, most likely.

Actually no.  It isn't useful and was only important to make the 
point that it was a "protocol-type" as opposed to merely a 
"protocol-id."

If there was a "protocol-instance-id" I would think it would be more 
useful if one left the protocol out of it entirely.  Of course, then 
it would be a port-id.  ;-)

>
>>That it is used
>>to identify the kind of protocol in the layer above, i.e. as you say,
>>the type.  But why is it necessary to identify the "protocol-type"? Why
>>are there such fields in IP and Ethernet? "Type" is not really required
>>for multiplexing.  There are much more flexible ways to identify flows
>>for multiplexing.
>
>Type is required to demultiplex different upper layer protocols 
>(here, network layers) that share a lower layer protocol (here, 
>ethernet).
>
>Again, type is distinct from flow.

Most definitely.  That is my point.

>
>>Why does the receiver need to know the type of protocol?  Perhaps so it
>>knows how to interpret the header in the layer above?
>
>Yes, that's what I said several times ;-)

Excellent! then you agree!  The purpose of the protocol-id field in 
IP is identify the syntax of the encapsulated protocol.

>The only way around that is to indicate it out-of-band, e.g., in a 
>different layer, and tie it to identifiers (demultiplexing of type 
>or instance) at other layers or to a physical entity (a single 
>physical link that isn't demuxed). The latter is more like a circuit.

Not of my concern.

Good discussion, Joe.

Take care,
John

>Joe