[e2e] Port numbers in the network layer?

[Joe Touch]

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.

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

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

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

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

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

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

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

;-)

Joe