[e2e] Port numbers in the network layer?

[Joe Touch]

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

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

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.

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

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

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

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

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

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

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

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

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

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

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.

Joe