<!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.&nbsp; 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.&nbsp;&nbsp; The binding
that thwarts mobility was the binding between the 32-bit address and
network physical topology.&nbsp; 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.&nbsp; 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 &quot;managerial&quot;
not topological under all proposals - was under active discussion as
*the* ultimate routing approach.&nbsp; The alternative that those of
us focused on &quot;internetworking&quot; and not just ARPANET
improvement were also considering was some form of &quot;hash based&quot;
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">&nbsp;</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">&nbsp;</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 &quot;mobility&quot; was omitted is just not
valid.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</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 &quot;endpoint
identifier&quot; 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">&nbsp;</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.&nbsp; We were
planning to handle efficient routing to these across alternative paths
by using the source-routing mechanism.&nbsp; (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">&nbsp;</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.&nbsp; In fact, a bunch of
idiots call UDP the &quot;unreliable&quot; datagram protocol, which
was not at all the point.&nbsp; 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">&nbsp;</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.&nbsp; Rather ignorant ones, who did not ever read Parnas, did
not understand control theory, imagined that TCP was &quot;sender
controlled&quot;, etc.</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font
face="Times New Roman">&nbsp;</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, &quot;Joe Touch&quot;
&lt;touch@ISI.EDU&gt; said:</font><br>
<font face="Times New Roman"></font></blockquote>
<blockquote type="cite" cite><font face="Times New Roman">&gt; Hi,
John,<br>
&gt;<br>
&gt; On 5/2/2013 4:42 PM, John Day wrote:<br>
&gt; ...<br>
&gt; &gt;&gt;&gt; The argument for the pseudoheader has always been a
bit shaky. No<br>
&gt; other<br>
&gt; &gt;&gt;&gt; Transport Protocol except UDP either within or
outside the IETF<br>
&gt; found<br>
&gt; &gt;&gt;&gt; the need for it. There have been many discussions
about removing<br>
&gt; it,<br>
&gt; &gt;&gt;&gt; but as you know tradition has always won out.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The pseudoheader is an artifact of the TCP/IP split,
which isn't as<br>
&gt; &gt;&gt; clean as often claimed.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It is used in other transport protocols built on IP,
e.g., DCCP and<br>
&gt; SCTP.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It is not a matter of tradition; it is deeply entrenched
with the<br>
&gt; &gt;&gt; notion of endpoint and that this notion exists at two
different layers<br>
&gt; &gt;&gt; that share at least some of the context (IP
addresses).<br>
&gt; &gt;<br>
&gt; &gt; &quot;Deeply entrenched,&quot; indeed. (Some would say a
synonym for tradition.)<br>
&gt; &gt; Strongly reasoned, less so. As recently described by its
author, it is<br>
&gt; &gt; this binding that thwarts mobility.<br>
&gt; &gt;<br>
&gt; &gt; Indeed this &quot;notion&quot; exists in two different
layers. In fact, it is a<br>
&gt; &gt; general property of all layers. But I fail to see how that
is an<br>
&gt; &gt; argument to require a pseudo-header.<br>
&gt;<br>
&gt; It's an argument that it IS required in all current Internet
transports.<br>
&gt; 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">&gt;
protocol in the Internet, or in other new stacks.<br>
&gt;<br>
&gt; ...<br>
&gt; &gt;&gt;&gt;&gt;&gt; According to this socket pair definition
then, is the<br>
&gt; connection id a<br>
&gt; &gt;&gt;&gt;&gt;&gt; Network Layer identifier or a Transport
Layer identifier?<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Transport layer ID that is based on a transport
header that<br>
&gt; subsumes a<br>
&gt; &gt;&gt;&gt;&gt; subset of the network header.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Huh? Next you are going to tell me that it is
&quot;small, green and<br>
&gt; split<br>
&gt; &gt;&gt;&gt; three ways&quot;! ;-)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The transport layer flow is *defined* as the socket
pair, which is<br>
&gt; &gt;&gt; defined in TCP (and used in other Internet transports)
as combining<br>
&gt; &gt;&gt; the transport header context (port pair) with the IP
context (IP<br>
&gt; &gt;&gt; address pair), the latter of which is part of the
pseudoheader for<br>
&gt; &gt;&gt; that reason.<br>
&gt; &gt;<br>
&gt; &gt; I realize this is the definition, and I would even agree
with including<br>
&gt; &gt; the same error-check-code, if they were in the same layer.
But since it<br>
&gt; &gt; is said they aren't, I fail to see the need and I definitely
see the<br>
&gt; &gt; constraints.<br>
&gt; &gt;<br>
&gt; &gt; Is there some condition in which a router might put a TCP
packet on a<br>
&gt; &gt; different IP packet? The only reason I can see for having
it.<br>
&gt;<br>
&gt; A router should never do anything to the contents of an IP
payload, IMO.<br>
&gt;<br>
&gt; However, isn't that the definition of how a NAT works?<br>
&gt;<br>
&gt; ...<br>
&gt; &gt;&gt; So I interpret &quot;protocol-id&quot; as I think most
people do.<br>
&gt; &gt;<br>
&gt; &gt; Excellent. That was my point. The field has the wrong
name.<br>
&gt;<br>
&gt; Yes, but when we're talking about existing protocols, the name is
there.<br>
&gt; New protocols might use more accurate terms, just as IPv6 has
a<br>
&gt; &quot;hopcount&quot; instead of a &quot;TTL&quot;.<br>
&gt;<br>
&gt; ...<br>
&gt; &gt; If there was a &quot;protocol-instance-id&quot; I would
think it would be more<br>
&gt; &gt; useful if one left the protocol out of it entirely. Of
course, then it<br>
&gt; &gt; would be a port-id. ;-)<br>
&gt;<br>
&gt; The destination port ID in a SYN encodes the service protocol,
which is<br>
&gt; a protocol-type-id. It isn't an instance-id; the instance-id is
the<br>
&gt; combination of the IP addresses and port numbers taken as a
set.<br>
&gt;<br>
&gt; &gt;&gt;&gt; Why does the receiver need to know the type of
protocol? Perhaps so<br>
&gt; it<br>
&gt; &gt;&gt;&gt; knows how to interpret the header in the layer
above?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Yes, that's what I said several times ;-)<br>
&gt; &gt;<br>
&gt; &gt; Excellent! then you agree! The purpose of the protocol-id
field in IP<br>
&gt; &gt; is identify the syntax of the encapsulated protocol.<br>
&gt;<br>
&gt; Yes. Same for the destination port of the initial SYN in TCP.<br>
&gt;<br>
&gt; ...<br>
&gt; &gt; Good discussion, Joe.<br>
&gt;<br>
&gt; Back at ya' ;-)<br>
&gt;<br>
&gt; Joe<br>
&gt;</font></blockquote>
<div><br></div>
</body>
</html>