Re: Port numbers in the network layer?

Thanks, Dave.  Those emails clarify a lot.

At 7:53 AM -0400 5/3/13, [email protected] wrote:
>The binding of a pseudoheader does not thwart mobility.   The 
>binding that thwarts mobility was the binding between the 32-bit 
>address and network physical topology.  The actual authors of the 
>pseudoheader *idea* which was proposed in the same Marina del Rey 
>meeting where the split of layers was sketched (by about 5 of us).to 
>create TCP, UDP, .... on top of a common IP actually occurred at a 
>time when routing was not *defined* to be prefix-based.  In fact, at 
>that same meeting, source routing (with route services providing 
>routes on demand along the way to be cached) - separate from the 
>32-bit address space, which was expected to be "managerial" not 
>topological under all proposals - was under active discussion as 
>*the* ultimate routing approach.  The alternative that those of us 
>focused on "internetworking" and not just ARPANET improvement were 
>also considering was some form of "hash based" routing at gateways 
>(i.e. totally non-physical).
>
>
>
>Source routing, like the pseudoheader, was very much a modular element of IP.
>
>
>
>Now this rewrite of history that implies that conflating addressing 
>and routing was inherent, so that "mobility" was omitted is just not 
>valid.
>
>
>
>I do agree technically that there might have been a better "endpoint 
>identifier" on an end-to-end basis than the pseudoheader turned out 
>to be (especially due to the much later decision to conflate 
>endpoint-identifier with route that got made by default at BBN, 
>perhaps just to get the thing bootstrapped).
>
>
>
>I can provide more evidence of this: for example, it was expected 
>that MIT's address space included mobile devices and subnets (we 
>were doing packet radio and LANs), as did Xerox PARC's PUP.  We were 
>planning to handle efficient routing to these across alternative 
>paths by using the source-routing mechanism.  (as you may know I 
>wrote, with Jerry Saltzer, a well-known paper on why source routing 
>was good).
>
>
>
>But hey, no one wants to understand the actual design.  In fact, a 
>bunch of idiots call UDP the "unreliable" datagram protocol, which 
>was not at all the point.  Instead it was a demultiplexing layer 
>that enabled a range of useful non-circuit oriented (M2M) protocols 
>to be designed.
>
>
>
>But the inmates grabbed hold of the asylum at some point in the 
>history of IETF.  Rather ignorant ones, who did not ever read 
>Parnas, did not understand control theory, imagined that TCP was 
>"sender controlled", etc.
>
>
>
>
>
>
>
>
>
>On Thursday, May 2, 2013 7:58pm, "Joe Touch" <[email protected]> said:
>
>  > Hi, John,
>>
>>  On 5/2/2013 4:42 PM, John Day wrote:
>>  ...
>>  >>> 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.
>>
>>  It's an argument that it IS required in all current Internet transports.
>>  It is NOT an argument that it has to be required in a new transport
>  > protocol in the Internet, or in other new stacks.
>>
>>  ...
>>  >>>>> 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.
>>
>>  A router should never do anything to the contents of an IP payload, IMO.
>>
>>  However, isn't that the definition of how a NAT works?
>>
>>  ...
>>  >> So I interpret "protocol-id" as I think most people do.
>>  >
>>  > Excellent. That was my point. The field has the wrong name.
>>
>>  Yes, but when we're talking about existing protocols, the name is there.
>>  New protocols might use more accurate terms, just as IPv6 has a
>>  "hopcount" instead of a "TTL".
>>
>>  ...
>>  > 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. ;-)
>>
>>  The destination port ID in a SYN encodes the service protocol, which is
>>  a protocol-type-id. It isn't an instance-id; the instance-id is the
>>  combination of the IP addresses and port numbers taken as a set.
>>
>>  >>> 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.
>>
>>  Yes. Same for the destination port of the initial SYN in TCP.
>>
>>  ...
>>  > Good discussion, Joe.
>>
>>  Back at ya' ;-)
>>
>>  Joe
>>