5 May 2013 00:25
Re: Port numbers in the network layer?
John Day <jeanjour <at> comcast.net>
2013-05-04 22:25:21 GMT
2013-05-04 22:25:21 GMT
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 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" <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
> 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
>
>>>=20
>>> I totally agree that things could go either way - SDN (like active =
>>nets before it) could go horribly horribly wrong....
>>>=20
>>> on the other hand, i suppose, it would then not get adopted much...
>>>=20
>>>=20
>>> On Sun, Apr 14, 2013 at 5:40 PM, <dpreed <at> reed.com> wrote:
>>> Jon - I strongly disagree with your views that SDN *will* solve the =
>>problem of simplifying network architecture and that computer scientists =
>>today are capable of architecting systems much better than those 40 =
>>years ago. I don't have a problem with SDN technology per se, but it =
>>changes very little in regard to most aspects of quality network design =
>>and architecture.
>>> [usual disclaimer about my posts being blocked to the full e2e list, =
>>but I invited to the conversation some people who might agree or =
>>disagree, because I think it's an interesting question]
>>> =20
>>> As someone who has worked on SDN (with McKeown's own code, at HP =
>>Labs), I think it can go either way -
>>> =20
>>> 1) do a better job of moving flexibility and function to the edges, or
>>> 2) create a vast nightmarish terrain of virtual middleboxes that do =
>>unpredictable and random things to traffic packets.
>>> =20
>>> Having seen what the deployers of middleboxes get wrong, I'm not sure =
>>that a virtualization platform for middleboxes will do to reduce the =
>>problems. It's a sociopolitical problem, not a technical one.
>>> =20
>>> Inside a company, where the fabric is completely owned and operated by =
>>a unified IT dept. (there is much evidence that IT dept's in large =
>>companies are hardly unified, though), SDN's can be extremely helpful - =
>>precisely because the network is virtualized by SDN. You can roll out =
>>changes in a coordinated fashion, orchestrate resilience in the face of =
>>faults and signficant load changes, etc. All that is quite doable, even =
>>while preserving the essential separation between transport and =
>>heterogeneous infrastructure. That separation is quite important to the =
>>long-term nature of the systems that use any network.
>>> =20
>>> However, the mess that is evolving in IPv4 comes from poorly thought =
>>out regulations (wiretapping and "firewall" mechanisms that try to =
>>operate at a level where there is no end-point semantics, for example) =
>>and a struggle to create business "control points" that can be =
>>monopolized.
>>> =20
>>> Merely emulating that mess (perfectly feasible with SDN) creates the =
>>opportunity to ramify the process of chaotic evolution of the network.
>>> =20
>>> As far as your view that modern computer science and computer =
>>scientists can now do what we couldn't do 40 years ago, I'm =
>>extraordinarily skeptical. Modern computer scientists (the people) are =
>>much less capable of clean architectural thinking on the average, and =
>>being faced with problems with a vast increase in interactions among =
>>uncontrollable factors.
>>> =20
>>> This is why I continue to complain about network pedagogy that starts =
>>with the idea that networks somehow live in a world of stationary random =
>>processes that are all Gaussian, and that there is a "central limit =
>>theorem" that therefore makes aggregation reduce complexity. I've even =
>>heard someone say that there may be a little bit of "fractal" structure, =
>>but that it is "drowned out" by Gaussian stationary traffic. Anyone who =
>>understood the actual math would be appalled, but computer scientists =
>>*pretend* to be mathematicians for the most part, applying cookbook =
>>formulas and "gut instincts" that they got by solving simple textbook =
>>exercises and watching lectures without questioning assumptions, and =
>>never challenging their professors.
>>> =20
>>> 40 years ago, there was not so much teachiing of "things that we know =
>>that 'taint so" as the phrase goes. So in that sense, today's computer =
>>scientists have a herd instinct that never questions anything, and =
>>worse, feels completely empowered to disregard those who don't agree =
>>with the consensus, no matter how well they put the alternative forth.
>>> =20
>>> How else did we end up in a place where nearly every access network =
>>has key links where "bufferbloat" can allow a single person to run an =
>>application that builds up a blockage in either the downlink or the =
>>uplink, creating latencies of 1-4 seconds when the nominal latency is on =
>>the order of < 10 msec and the cross-country latency including all hops =
>>is around 30 msec? Was this "expertise by computer scientists"? =
>>Hardly. It was vastly ramified result of ignorance, not expertise.
>>> =20
>>> And worse, NO ONE in the community bothers to actually measure the =
>>real Internet in any detail. That would make their publications in =
>>academic journals be suspect, and eliminate the cozy world of =
>>conferences that seem to be more like a mutual admiration society among =
>>an isolated elite.
>>> =20
>>> So I'm skeptical that there is this wonderful world of computer =
>>scientists that have mastered anything.
>>> =20
>>> Some people in the community are pretty damn smart. Too few. Most are =
>>mis-employed.
>>> =20
>>> So, in the case of SDN, I'm pretty sure that the mess will continue to =
>>get worse due precisely to the ease with which SDN enables the blind =
>>deployment of bad ideas, and does not enhance the ability to detect the =
>>effects of bad ideas, measure their problems, and chuck the bad ideas.
>>> =20
>>> SDN becomes an accelerator of a network Gresham's Law, if that is the =
>>way things go.
>>> =20
>>> Nonetheless, SDN is a really helpful concept, put in its place - =
>>virtualization can be enormously helpful when it creates a simple =
>>abstraction without "cross-layer optimization".
>>> =20
>>> And don't get me started on the academic fascination in computer =
>>science with how "great" cross-layer optimizations are. Next we'll have =
>>thousands of papers talking about the wonders of kludges and crocks in =
>>network designs.
>>> =20
>>>=20
>>>=20
>>> On Sunday, April 14, 2013 6:04am, "Jon Crowcroft" =
>><jon.crowcroft <at> cl.cam.ac.uk> said:
>>>=20
>>> I think you can look at it a different way - SDN lets you move even =
>>more smarts out of the network into end systems - as far as we implement =
>>it, that looks even less like the ITU than the current =
>>ancient-route-computation/firewall/middlebox ridden IPv4 ossification of =
>>today
>>> so i can see that you could cast SDN in the Wicked Witch of the ITU =
>>role, but equally, I think of it as not being in Kansas anymore....
>>> cheers
>>> jon
>>>=20
>>>=20
>>> On Sat, Apr 13, 2013 at 10:39 PM, John Day <jeanjour <at> comcast.net> =
>>wrote:
>>> Yea, I have seen their stuff too, pretty amusing. about as disruptive =
>>as a speed bump. 
RSS Feed