[e2e] Port numbers in the network layer?
jeanjour at comcast.net
Sat May 4 15:25:21 PDT 2013
Thanks, Dave. Those emails clarify a lot.
At 7:53 AM -0400 5/3/13, dpreed at reed.com 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
>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
>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" <touch at ISI.EDU> 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
>> >>> Transport Protocol except UDP either within or outside the IETF
>> >>> the need for it. There have been many discussions about removing
>> >>> 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
>> >> 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
>> >>> 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
>> >>> 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' ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest