[e2e] Port numbers in the network layer?

[John Day]

Sorry, I got a bit busy and then this got lost on my desktop.

At 8:27 PM -0700 4/28/13, Joe Touch wrote:
>On 4/26/2013 9:11 PM, John Day wrote:
>>At 5:42 PM -0700 4/26/13, Joe Touch wrote:
>>>On 4/26/2013 3:30 PM, John Day wrote:
>>>>At 11:46 AM -0700 4/25/13, Joe Touch wrote:
>>>>>One issue is the need for ports; there's a summary of that here:
>>>>>
>>>>>http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01
>>>>>
>>>>>Its use evolved to overload:
>>>>>
>>>>>     - part of the stream identifier used to associate groups
>>>>>     of packets (with IP addresses)
>>>>
>>>>The source and destination port-ids form a connection(flow)-identifier.
>>>
>>>In the Internet, the IP addresses are part of that connection ID,
>>>called the socket pair.
>>
>>I was speaking generally.  With point to point links, you can have
>>multiple connections but no need for addresses.  But a connection-id is
>>still necessary.
>
>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.  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.

>
>>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.

>
>>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.

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.

>
>>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"!  ;-)

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.

>>>>>     - 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.

>...
>>>>>Similarly we could allocate a new ethertype to "IPv4:TCP" or
>>>>>"IPv4:SCTP".
>>>>
>>>>What about IPv4:TCP1 thru IPv4:TCP1000?
>>>
>>>I was clearly trying to extrapolate only different protocol stack
>>>combinations. If you're referring to variants of TCP, those could
>>>either be in a single ethertype or 1000 different ones. If you're
>>>referring to specific connections, that's a different semantic that
>>>doesn't map to my example about ethertypes.
>>
>>If Protocol-id is to identify the Protocol in the layer above (and not
>>just the syntax), then I would assume that I should be able to have
>>multiple instances of the same protocol.
>
>It might be informative for you to explain that logic.

See below.

>>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.

Given how it is used, it can't be a protocol-id field.  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.

Why does the receiver need to know the type of protocol?  Perhaps so 
it knows how to interpret the header in the layer above?

>
>>>>>So any "mix and match" architecture needs to have some indication of
>>>>>what the particular mix is, but it need not be cascaded layer-by-layer.
>>>>
>>>>If I understand what you mean by "some indication" I would have to say
>>>>no it is not required.
>>>
>>>"some indication" means either a preexisting agreement at the
>>>endpoints or a label either in-band or out-of-band. You can't
>>>differentiate various types of stack combinations without any
>>>information.
>>
>>You would be surprised what can happen.
>
>Assertions do not surprise me; only counterexamples.
>
>;-)

Indeed. But this email is already too long.  ;-)  I think there is a 
reference someplace for this.  I will have to find it.

Take care,
John

>Joe