<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [e2e] Port numbers in the network
layer?</title></head><body>
<div>Thanks, Dave. Those emails clarify a lot.</div>
<div><br></div>
<div>At 7:53 AM -0400 5/3/13, dpreed@reed.com wrote:</div>
<blockquote type="cite" cite><font face="Times New Roman">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).</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">Source
routing, like the pseudoheader, was very much a modular element of
IP.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">Now this
rewrite of history that implies that conflating addressing and routing
was inherent, so that "mobility" was omitted is just not
valid.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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).</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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).</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">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.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman"> </font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman"><br>
<br>
On Thursday, May 2, 2013 7:58pm, "Joe Touch"
<touch@ISI.EDU> said:</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">> Hi,
John,<br>
><br>
> On 5/2/2013 4:42 PM, John Day wrote:<br>
> ...<br>
> >>> The argument for the pseudoheader has always been a
bit shaky. No<br>
> other<br>
> >>> Transport Protocol except UDP either within or
outside the IETF<br>
> found<br>
> >>> the need for it. There have been many discussions
about removing<br>
> it,<br>
> >>> but as you know tradition has always won out.<br>
> >><br>
> >> The pseudoheader is an artifact of the TCP/IP split,
which isn't as<br>
> >> clean as often claimed.<br>
> >><br>
> >> It is used in other transport protocols built on IP,
e.g., DCCP and<br>
> SCTP.<br>
> >><br>
> >> It is not a matter of tradition; it is deeply entrenched
with the<br>
> >> notion of endpoint and that this notion exists at two
different layers<br>
> >> that share at least some of the context (IP
addresses).<br>
> ><br>
> > "Deeply entrenched," indeed. (Some would say a
synonym for tradition.)<br>
> > Strongly reasoned, less so. As recently described by its
author, it is<br>
> > this binding that thwarts mobility.<br>
> ><br>
> > Indeed this "notion" exists in two different
layers. In fact, it is a<br>
> > general property of all layers. But I fail to see how that
is an<br>
> > argument to require a pseudo-header.<br>
><br>
> It's an argument that it IS required in all current Internet
transports.<br>
> It is NOT an argument that it has to be required in a new
transport</font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">>
protocol in the Internet, or in other new stacks.<br>
><br>
> ...<br>
> >>>>> According to this socket pair definition
then, is the<br>
> connection id a<br>
> >>>>> Network Layer identifier or a Transport
Layer identifier?<br>
> >>>><br>
> >>>> Transport layer ID that is based on a transport
header that<br>
> subsumes a<br>
> >>>> subset of the network header.<br>
> >>><br>
> >>> Huh? Next you are going to tell me that it is
"small, green and<br>
> split<br>
> >>> three ways"! ;-)<br>
> >><br>
> >> The transport layer flow is *defined* as the socket
pair, which is<br>
> >> defined in TCP (and used in other Internet transports)
as combining<br>
> >> the transport header context (port pair) with the IP
context (IP<br>
> >> address pair), the latter of which is part of the
pseudoheader for<br>
> >> that reason.<br>
> ><br>
> > I realize this is the definition, and I would even agree
with including<br>
> > the same error-check-code, if they were in the same layer.
But since it<br>
> > is said they aren't, I fail to see the need and I definitely
see the<br>
> > constraints.<br>
> ><br>
> > Is there some condition in which a router might put a TCP
packet on a<br>
> > different IP packet? The only reason I can see for having
it.<br>
><br>
> A router should never do anything to the contents of an IP
payload, IMO.<br>
><br>
> However, isn't that the definition of how a NAT works?<br>
><br>
> ...<br>
> >> So I interpret "protocol-id" as I think most
people do.<br>
> ><br>
> > Excellent. That was my point. The field has the wrong
name.<br>
><br>
> Yes, but when we're talking about existing protocols, the name is
there.<br>
> New protocols might use more accurate terms, just as IPv6 has
a<br>
> "hopcount" instead of a "TTL".<br>
><br>
> ...<br>
> > If there was a "protocol-instance-id" I would
think it would be more<br>
> > useful if one left the protocol out of it entirely. Of
course, then it<br>
> > would be a port-id. ;-)<br>
><br>
> The destination port ID in a SYN encodes the service protocol,
which is<br>
> a protocol-type-id. It isn't an instance-id; the instance-id is
the<br>
> combination of the IP addresses and port numbers taken as a
set.<br>
><br>
> >>> Why does the receiver need to know the type of
protocol? Perhaps so<br>
> it<br>
> >>> knows how to interpret the header in the layer
above?<br>
> >><br>
> >> Yes, that's what I said several times ;-)<br>
> ><br>
> > Excellent! then you agree! The purpose of the protocol-id
field in IP<br>
> > is identify the syntax of the encapsulated protocol.<br>
><br>
> Yes. Same for the destination port of the initial SYN in TCP.<br>
><br>
> ...<br>
> > Good discussion, Joe.<br>
><br>
> Back at ya' ;-)<br>
><br>
> Joe<br>
></font></blockquote>
<div><br></div>
</body>
</html>