From braden at ISI.EDU Thu Oct 15 13:05:04 2009
From: braden at ISI.EDU (Bob Braden)
Date: Thu, 15 Oct 2009 13:05:04 -0700
Subject: [e2e] draft-d-sec-udt-00.txt
Message-ID: <4AD78070.3080509@isi.edu>
I am writing this with my Independent Stream Editor hat on.
The draft "Security Requirements for UDT" has been submitted. It is
deeply confused as a document, but it is building on apparently
legitimate (if not necessary worthy) academic publications on a reliable
transport protocol to run over UDP, called UDT. UDT seems to have its
own congestion control algorithm.
If there is someone on this list who is feeling particularly jagged
today and would like to write a short review of this document, it would
be a help. I am always nagged by the fear that there is really something
hidden beneath the confusion that deserves to be teased out, and in any
case authors deserve good reasons for rejecting their work.
Any takers? BTW, the document is ~ 6 pages.
Bob Braden
From mateosj at tcd.ie Fri Oct 23 03:26:54 2009
From: mateosj at tcd.ie (Jaime Mateos)
Date: Fri, 23 Oct 2009 11:26:54 +0100
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <4AE184EE.5040800@tcd.ie>
Hi,
I'm working on a project about the current challenges the Internet is
presenting to the end-to-end argument. I'd be interested to know about
any protocols, currently in use, that break the end-to-end principle and
the context where they are used. So far the only one I've found is TCP
PEP that seems to be in use in satellite networks (Internetworking and
computing over satellite networks, Yongguang Zhang -
http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false)
There also seems to be a number of research projects such as Split TCP
and LTP-T that I've come across. I'm also interested in these but not to
the same degree as in protocols that are currently in use today.
Thanks,
Jaime Mateos
From jeroen at unfix.org Fri Oct 23 03:58:59 2009
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 23 Oct 2009 12:58:59 +0200
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE184EE.5040800@tcd.ie>
References: <4AE184EE.5040800@tcd.ie>
Message-ID: <4AE18C73.7000208@spaghetti.zurich.ibm.com>
Jaime Mateos wrote:
> Hi,
> I'm working on a project about the current challenges the Internet is
> presenting to the end-to-end argument. I'd be interested to know about
> any protocols, currently in use, that break the end-to-end principle and
> the context where they are used.
Everything that needs an NAT helper, thus any protocol that embeds
addresses or ports, thus most games, everything that has a listening
port where the listening port is not on a public IP or firewalled away.
Greets,
Jeroen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/514f1076/signature.bin
From L.Wood at surrey.ac.uk Fri Oct 23 04:47:00 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Fri, 23 Oct 2009 12:47:00 +0100
Subject: [e2e] Protocols breaking the end-to-end argument
References: <4AE184EE.5040800@tcd.ie>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
Hey, I wrote a chapter of that book...
Do look into the Bundle Protocol, which ignore the end-to-end
principle and control loops in its design. See our 'Bundle of
Problems' paper for more on this:
http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/
The Bundle Protocol has similar problems/oversights as LTP-T.
Carlo Caini's group has drawn parallels between
DTN work and TCP PEPs, pointing out that what TCP PEPs do
on the quiet (break the end-to-end control loop into separate
loops) is what things like bundle hops + convergence layers
or http proxy caches do more explicitly and visibly. See e.g.
his IWSSC'09 paper:
"TCP, PEP and DTN Performance on Disruptive Satellite Channels."
L.
-----Original Message-----
From: end2end-interest-bounces at postel.org on behalf of Jaime Mateos
Sent: Fri 2009-10-23 11:26
To: end2end-interest at postel.org
Subject: [e2e] Protocols breaking the end-to-end argument
Hi,
I'm working on a project about the current challenges the Internet is
presenting to the end-to-end argument. I'd be interested to know about
any protocols, currently in use, that break the end-to-end principle and
the context where they are used. So far the only one I've found is TCP
PEP that seems to be in use in satellite networks (Internetworking and
computing over satellite networks, Yongguang Zhang -
http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false)
There also seems to be a number of research projects such as Split TCP
and LTP-T that I've come across. I'm also interested in these but not to
the same degree as in protocols that are currently in use today.
Thanks,
Jaime Mateos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/13283de1/attachment.html
From william.allen.simpson at gmail.com Fri Oct 23 05:39:48 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Fri, 23 Oct 2009 08:39:48 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE184EE.5040800@tcd.ie>
References: <4AE184EE.5040800@tcd.ie>
Message-ID: <4AE1A414.4090302@gmail.com>
Jaime Mateos wrote:
> I'm working on a project about the current challenges the Internet is
> presenting to the end-to-end argument. I'd be interested to know about
> any protocols, currently in use, that break the end-to-end principle and
> the context where they are used.
You could add the Broadcom chip sets to your list. Not a protocol per se,
but they inexplicably "handle" TCP segmentation. Usually used in a host
(bad enough in my opinion), but could create utter havoc in a router.
So far, I've noticed:
NetXtreme II 1 Gigabit
Tigon 3
When I recently proposed actually checking for correct TCP option sizes,
the Linux driver's author says:
You're being way too anal here, and adding these checks to
drivers would be just a lot of rediculious bloat. [sic]
From dpreed at reed.com Fri Oct 23 07:20:47 2009
From: dpreed at reed.com (David P. Reed)
Date: Fri, 23 Oct 2009 10:20:47 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
References: <4AE184EE.5040800@tcd.ie>
<4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
Message-ID: <4AE1BBBF.2090109@reed.com>
I'd reframe the statement, just because I would actually like the term
"end-to-end argument" to continue to mean what we defined it to mean,
rather than what some people have extended it to mean.
So I think what you are looking for is a set of examples that
demonstrate functions that are "best done inside the network".
If you read the original paper, there is no claim whatever that says either:
1) that all functions should be done at the edges. (this radical
proposition, however, is one that guides some of my personal
interests in researching how far one can go. But that's a "Reed
research guideline" not an architecture argument.)
2) that one should never include optimizations of functions that
must (to be correct) be done at the edges, in the network.
Yet each interpretation above (and some others) are used occasionally.
Here's an example that challenges 2) and 1) but not the original
argument: where should congestion measurement be done, in order to
support congestion control?
Congestion *exists* only inside the network, by definition. So it must
be measured in the network.
However, where should *control* of congestion happen? That's a very
different story. It can't happen at the places where it is measured...
because congestion is an emergent phenomenon that depends on details at
the edges, AND on routing decisions (and traffic engineering and
investment decisions, as well, at slower rates of change). The answer
would be easy if there were one perfect place to do it. Of course, the
network itself makes that hard.
Today's Internet offers a variety of measures of congestion: measured
changes of RTT end-to-end at each of the hosts that share a bottleneck
subpath for active traffic, packet drops, packet-pair tests, marks such
as ECN, SNMP-if-it-had-a-MIB, ...
It also offers a variety of ways to mitigate congestion: get one or more
senders to slow down, get the sender to recode using more compression,
force some of the traffic to an alternate path, etc.
Choices of how to implement the congestion management function (which
includes traffic engineering as a subroutine) can be informed by the
"end-to-end argument" if you break the function down into subfunctions.
But this is not a problem with the "end-to-end argument". It is a
problem with TCP RTP and other protocols over IP, and routers that we
have today.
We have, for example, ECN as a tool implemented by routers. Turning it
on probably would help a reasonable amount. ECN itself is a solution to
congestion *measurement*, not mitigation. Measurement in the router,
communicated by ECN to all who share the bottleneck path, is clearly a
function "in the network". And yet it satisfies the end-to-end argument!
Lest we think that congestion control is the only area where *careful
thinking* is informed by end-to-end arguments about function placement,
there are many that fit the original argument. Blocking hostile DDOS
attacks is another. It's hard to imagine that anyone could argue that
DDOS against a target could be prevented solely outside the network.
However, *prosecution* of the offenders is clearly not a function that
can be done inside the network. Similarly, it would be silly to burden
a router with the job of collecting evidence for the prosecutor. There
are actually two kinds of DDOS attacks:
1) against the network itself,
2) against a particular end host (or hosts).
The former can be detected reliably by the network elements involved.
The latter must be defined by the host itself... since it is the host
who desires or doesn't desire a lot of traffic aimed at it.
Let's look at the latter, only. It would be silly for the operator of
the network to have to look at packets flowing to a web server to detect
that many SYNs are sent, but the 3rd step of the handshake is
uncompleted. The server is the only reliable place to verify that its
time is being wasted by many open connnections.
Yet responding to the DDOS attack may be helped by disconnecting the
sources. This has to be a network function on a large scale. And
tracing back to the source may be a network function.
On 10/23/2009 07:47 AM, L.Wood at surrey.ac.uk wrote:
>
> Hey, I wrote a chapter of that book...
>
> Do look into the Bundle Protocol, which ignore the end-to-end
> principle and control loops in its design. See our 'Bundle of
> Problems' paper for more on this:
> http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/
> The Bundle Protocol has similar problems/oversights as LTP-T.
>
> Carlo Caini's group has drawn parallels between
> DTN work and TCP PEPs, pointing out that what TCP PEPs do
> on the quiet (break the end-to-end control loop into separate
> loops) is what things like bundle hops + convergence layers
> or http proxy caches do more explicitly and visibly. See e.g.
> his IWSSC'09 paper:
> "TCP, PEP and DTN Performance on Disruptive Satellite Channels."
>
> L.
>
>
>
>
>
> -----Original Message-----
> From: end2end-interest-bounces at postel.org on behalf of Jaime Mateos
> Sent: Fri 2009-10-23 11:26
> To: end2end-interest at postel.org
> Subject: [e2e] Protocols breaking the end-to-end argument
>
> Hi,
> I'm working on a project about the current challenges the Internet is
> presenting to the end-to-end argument. I'd be interested to know about
> any protocols, currently in use, that break the end-to-end principle and
> the context where they are used. So far the only one I've found is TCP
> PEP that seems to be in use in satellite networks (Internetworking and
> computing over satellite networks, Yongguang Zhang -
> http://books.google.ie/books?id=3pkI6OWUsRAC&pg=PA170&lpg=PA170&dq=criticisms+of+end+to+end+principle&source=bl&ots=OVbMYc5Iso&sig=Tir1Xi4vxRG5HG2ieGCgl2STWcA&hl=en&ei=vL7TSor9Bs2z4QbW8_H_Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBQQ6AEwBA#v=onepage&q=criticisms%20of%20end%20to%20end%20principle&f=false)
>
>
> There also seems to be a number of research projects such as Split TCP
> and LTP-T that I've come across. I'm also interested in these but not to
> the same degree as in protocols that are currently in use today.
>
> Thanks,
> Jaime Mateos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/ff9b5e78/attachment-0001.html
From dhc2 at dcrocker.net Fri Oct 23 08:28:22 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Fri, 23 Oct 2009 08:28:22 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1BBBF.2090109@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com>
Message-ID: <4AE1CB96.3020203@dcrocker.net>
David P. Reed wrote:
> I'd reframe the statement, just because I would actually like the term
> "end-to-end argument" to continue to mean what we defined it to mean,
> rather than what some people have extended it to mean.
Interesting. My sense of things is that the term is not actually defined all
that concretely or consistently and that this has made it difficult to use the
term constructively.
Can you or anyone else point to a definition that
a) gives meaningful technical definition of "end to end", sufficient to make
differential conformance assessments reasonable.
b) provide any basis for believing that that definition has broad use within
the technical community?
Absent the ability to satisfy this query, we ought to consider an effort to move
towards being able to.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
From dpreed at reed.com Fri Oct 23 08:38:09 2009
From: dpreed at reed.com (David P. Reed)
Date: Fri, 23 Oct 2009 11:38:09 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1A414.4090302@gmail.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
Message-ID: <4AE1CDE1.5070205@reed.com>
On 10/23/2009 08:39 AM, William Allen Simpson wrote:
> You could add the Broadcom chip sets to your list. Not a protocol per
> se,
> but they inexplicably "handle" TCP segmentation. Usually used in a host
> (bad enough in my opinion), but could create utter havoc in a router.
>
> So far, I've noticed:
>
> NetXtreme II 1 Gigabit
> Tigon 3
This is an interesting observation, but I don't understand what you mean.
Explain "handling TCP segmentation" please? Exactly what chips do
that? What exactly do they do in the chip?
The chips might do IP fragmentation, but I find it hard to see how they
could do TCP segmentation, unless of course they are acting as a host.
Nothing wrong with a chipset being a host, too (perhaps to present a
web, ssh or SNMP interface).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/e5f8784a/attachment.html
From dpreed at reed.com Fri Oct 23 08:41:57 2009
From: dpreed at reed.com (David P. Reed)
Date: Fri, 23 Oct 2009 11:41:57 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1CB96.3020203@dcrocker.net>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net>
Message-ID: <4AE1CEC5.4000306@reed.com>
I'd suggest reading the paper where it was originally defined. Given
that the three authors AND a crew of peer reviewers touched every word
of the definition, it's pretty darned specific.
On 10/23/2009 11:28 AM, Dave CROCKER wrote:
>
>
> David P. Reed wrote:
>> I'd reframe the statement, just because I would actually like the
>> term "end-to-end argument" to continue to mean what we defined it to
>> mean, rather than what some people have extended it to mean.
>
>
> Interesting. My sense of things is that the term is not actually
> defined all that concretely or consistently and that this has made it
> difficult to use the term constructively.
>
> Can you or anyone else point to a definition that
>
> a) gives meaningful technical definition of "end to end",
> sufficient to make differential conformance assessments reasonable.
>
> b) provide any basis for believing that that definition has broad
> use within the technical community?
>
> Absent the ability to satisfy this query, we ought to consider an
> effort to move towards being able to.
>
> d/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/eec35888/attachment.html
From jnc at mercury.lcs.mit.edu Fri Oct 23 09:58:35 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 23 Oct 2009 12:58:35 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu>
> From: Dave CROCKER
> My sense of things is that the term is not actually defined all that
> concretely or consistently
Sorry, I disagree. The original Saltzer/Clark/Reed paper does a pretty
good job, I think - as well as one can do with a broad architectural
concept, which is inherently not as susceptible to precise definition as,
say, an algorithm.
> this has made it difficult to use the term constructively.
No, people being bozos and not using the term _as it wss originally
defined_ are what has made its use problematic.
Noel
From dpreed at reed.com Fri Oct 23 10:52:57 2009
From: dpreed at reed.com (David P. Reed)
Date: Fri, 23 Oct 2009 13:52:57 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1D4E6.2010105@bbiw.net>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net>
<4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net>
Message-ID: <4AE1ED79.2010604@reed.com>
Sorry - I figured everyone on this list knew the paper itself, since
it's cited all over the place, so I was being a little bit terse.
Anyway, one place you can get the original paper text is online at
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf .
We also wrote a followup paper in the "active networks" era that tries
to carefully explain how the same approach can be helpful in thinking
about "active networks":
http://web.mit.edu/Saltzer/www/publications/endtoend/ANe2ecomment.html
(this was published in IEEE Networking, or some other IEEE pub, as I
recall).
Some will remember that "active networking" was viewed as an idea that
made the end-to-end argument "obsolete" - I personally think that that
was a conclusion based on a misunderstanding about what we meant - and
this second paper refines the point we made in the first paper.
Saltzer, Clark, and I have separately extended and adapted the original
ideas. Perhaps the most interesting recent idea is Dave Clark's
unpublished talk and note which focuses on a "Trust-to-Trust principle"
that I have urged him to write up. I don't think it is published yet.
Dave and Marjorie Blumenthal have also written a paper on a range of
areas where policy functions might best be done in the network. I don't
have a link to it, but here's a citation. M. Blumenthal, D.
Clark,/Rethinking the Design of the Internet: The End-to-end Arguments
vs. the Brave New World/, ACM Transactions on Internet Technology,
1(1):70-109, August 2001 .
I can't help adding: Of course there are lots of people who use the word
"end-to-end" when they mean, for example, "TCP is perfect". (I'm not
one of them: I have about 40,000 complaints with TCP and IP, so it's
especially galling to be accused of claiming that TCP is the best of all
possible protocols - often as a straw man. TCP's merely good enough,
IMHO, to apply a different and older argument: if it ain't broke, don't
fix it. But by all means experiment with improvements and alternatives).
On 10/23/2009 12:08 PM, Dave CROCKER wrote:
> David,
>
> I'm asking to explore this carefully and inclusively.
>
> Since you are putting a reference forward, what is the citation to it?
>
> d/
>
>
> David P. Reed wrote:
>> I'd suggest reading the paper where it was originally defined. Given
>> that the three authors AND a crew of peer reviewers touched every
>> word of the definition, it's pretty darned specific.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/f057ce7b/attachment.html
From L.Wood at surrey.ac.uk Fri Oct 23 12:02:59 2009
From: L.Wood at surrey.ac.uk (Lloyd Wood)
Date: Fri, 23 Oct 2009 20:02:59 +0100
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1ED79.2010604@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net>
<4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net>
<4AE1ED79.2010604@reed.com>
Message-ID:
On 23 Oct 2009, at 18:52, David P. Reed wrote:
> Sorry - I figured everyone on this list knew the paper itself,
> since it's cited all over the place, so I was being a little bit
> terse. Anyway, one place you can get the original paper text is
> online at http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
> .
Worth stressing that there are actually multiple revisions of that
paper.
J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System
Design?, Second International Conference on Distributed Computing
Systems (April 1981) pages 509-512.
J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System
Design?, ACM Transactions in Computer Systems, pp. 277-288, November
1984.
http://doi.acm.org/10.1145/357401.357402
The version at Saltzer's webpages above is a third version, with page
numbering 1-10, but its footnote
on the first page is helpful at pointing out different versions.
http://en.wikipedia.org/wiki/End-to-end_principle
could be better...
L.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
From dpreed at reed.com Fri Oct 23 14:33:43 2009
From: dpreed at reed.com (David P. Reed)
Date: Fri, 23 Oct 2009 17:33:43 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net>
<4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net>
<4AE1ED79.2010604@reed.com>
Message-ID: <4AE22137.10909@reed.com>
Wikipedia article is not definitive. In particular, none of the 3
authors wrote the wikipedia article. In general, wikipedia does well
at some things, but I wouldn't trust it to read authors' words more
clearly than the authors themselves.
In particular: there was never an "end-to-end principle". So if you get
the title wrong, why should we trust you to get the details right?
Indeed the original paper was presented at a conference, selected for
ACM TOCS (and revised to their standards), and the last, online version
is slightly different. There was also a version that was circulated
prior to the 1981 conference among peers and friends - as was the
convention in the computer systems community - some of the examples in
the 1981 version were suggested during that phase.
On 10/23/2009 03:02 PM, Lloyd Wood wrote:
>
> On 23 Oct 2009, at 18:52, David P. Reed wrote:
>
>> Sorry - I figured everyone on this list knew the paper itself, since
>> it's cited all over the place, so I was being a little bit terse.
>> Anyway, one place you can get the original paper text is online at
>> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf .
>
> Worth stressing that there are actually multiple revisions of that paper.
>
> J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System
> Design?, Second International Conference on Distributed Computing
> Systems (April 1981) pages 509-512.
>
> J. Saltzer, D. Reed and D. Clark, ?End-to-End Arguments in System
> Design?, ACM Transactions in Computer Systems, pp. 277-288, November
> 1984.
> http://doi.acm.org/10.1145/357401.357402
>
> The version at Saltzer's webpages above is a third version, with page
> numbering 1-10, but its footnote
> on the first page is helpful at pointing out different versions.
>
> http://en.wikipedia.org/wiki/End-to-end_principle
> could be better...
>
> L.
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091023/5f15c7f9/attachment.html
From L.Wood at surrey.ac.uk Fri Oct 23 16:20:27 2009
From: L.Wood at surrey.ac.uk (Lloyd Wood)
Date: Sat, 24 Oct 2009 00:20:27 +0100
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE22137.10909@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk>
<4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net>
<4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net>
<4AE1ED79.2010604@reed.com>
<4AE22137.10909@reed.com>
Message-ID: <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk>
On 23 Oct 2009, at 22:33, David P. Reed wrote:
> In particular: there was never an "end-to-end principle". So if you
> get the title wrong, why should we trust you to get the details right?
because "end-to-end argument principle" is appalling grammar. The word
"principle" appears multiple times in the paper, including the
abstract and conclusions.
"No one gets angry at a mathematician or a physicist whom he or she
doesn't understand, or at someone who speaks a foreign language, but
rather at someone who tampers with your own language." -- Jacques
Derrida
http://mercury.lcs.mit.edu/~jnc/tech/end_end.html
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
From perfgeek at mac.com Fri Oct 23 18:47:52 2009
From: perfgeek at mac.com (rick jones)
Date: Fri, 23 Oct 2009 18:47:52 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE1CDE1.5070205@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
Message-ID: <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
On Oct 23, 2009, at 8:38 AM, David P. Reed wrote:
> On 10/23/2009 08:39 AM, William Allen Simpson wrote:
>>
>> You could add the Broadcom chip sets to your list. Not a protocol
>> per se,
>> but they inexplicably "handle" TCP segmentation. Usually used in a
>> host
>> (bad enough in my opinion), but could create utter havoc in a router.
>>
>> So far, I've noticed:
>>
>> NetXtreme II 1 Gigabit
>> Tigon 3
> This is an interesting observation, but I don't understand what you
> mean.
>
> Explain "handling TCP segmentation" please? Exactly what chips do
> that? What exactly do they do in the chip?
>
> The chips might do IP fragmentation, but I find it hard to see how
> they could do TCP segmentation, unless of course they are acting as
> a host. Nothing wrong with a chipset being a host, too (perhaps to
> present a web, ssh or SNMP interface).
Perhaps he is referring to chips which provide TCP/Transport
Segmentation Offload - aka TSO - the functionality that allows the
stack to hand the chip a chunk of data > the MTU, along with the
initial TCP/IP headers and the connection's on the wire MSS, and then
have the chip otherwise statelessly segment that larger chunk of data
into MSS-sized segments for transmission on the wire/fibre/etc.
If that is the functionality of which he speaks, it is in virtually
every contemporary 1GbE card I can think of (but my thoughts cannot
span the entirety of the space I suspect). Also, virtually every 10G
NIC out there offers the same functionality.
And if that upsets him, we better not tell him about the 10G NICs also
doing receive offload... :)
rick jones
BTW, I do not believe that any router actually has TSO happen to TCP
segments contained within the IP datagrams passing through it -
although there have been issues in Linux with LRO (Large Receive
Offload, distinct from General Receive Offload) when the system was
acting as either a router or a bridge - because TSO doesn't happen in
that path :)
http://homepage.mac.com/perfgeek
From perfgeek at mac.com Fri Oct 23 18:49:12 2009
From: perfgeek at mac.com (rick jones)
Date: Fri, 23 Oct 2009 18:49:12 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE18C73.7000208@spaghetti.zurich.ibm.com>
References: <4AE184EE.5040800@tcd.ie>
<4AE18C73.7000208@spaghetti.zurich.ibm.com>
Message-ID:
On Oct 23, 2009, at 3:58 AM, Jeroen Massar wrote:
> Jaime Mateos wrote:
>> Hi,
>> I'm working on a project about the current challenges the Internet is
>> presenting to the end-to-end argument. I'd be interested to know
>> about
>> any protocols, currently in use, that break the end-to-end
>> principle and
>> the context where they are used.
>
> Everything that needs an NAT helper, thus any protocol that embeds
> addresses or ports, thus most games, everything that has a listening
> port where the listening port is not on a public IP or firewalled
> away.
Isn't the sense incorrect there? I always thought it was the NAT
itself, and its need for helpers that was in opposition to the quasi-
mythical end-to-end principle?
rick jones
Wisdom teeth are impacted, people are affected by the effects of events
From richard at bennett.com Fri Oct 23 20:23:21 2009
From: richard at bennett.com (Richard Bennett)
Date: Fri, 23 Oct 2009 20:23:21 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com>
Message-ID: <4AE27329.3040801@bennett.com>
People who are interested in the evolution, refinement, application, and
re-definition of end-to-end arguments, principles, doctrines, dogmas,
and guidelines may enjoy my paper, "Designed for Change: End-to-End
Arguments, Internet Innovation, and the Net Neutrality Debate",
available at http://www.itif.org/index.php?id=294 along with a video of
a nice discussion of the stagnation of Internet protocol development
with Dave Farber, John Day, Chris Yoo, Bill Lehr, and yours truly.
I think Jaime's usage, "breaking end-to-end", is common in today's IETF,
where people tend to regard end system function placement as a default,
and the caveats of the Arguments are pretty much ignored. This kind of
reduction is to be expected, given the way that complex ideas tend to be
simplified by time.
The best discussion I've seen of function placement in a datagram
network to this day is found in Louis Pouzin's mongraph on the CYCLADES
network, _Cyclades Computer Network: Towards Layered Network
Applications_, Elsevier Science Ltd (September 1982). The book is out of
print, but it's available through interlibrary loan from several
institutions in the US. Pouzin takes a very pragmatic and empirical
approach to function placement, where later engineers tended to come
from first principles. The worst treatment is David Isenberg's second
"stupid network" paper, "Dawn of the Stupid Network"; it's much more
doctrinaire than "Rise of the Stupid Network" by the same dude.
A couple of great critiques of "End-to-End Args" are RFC 1958 and Tim
Moors' "A Critical Review of End-to-End Arguments in System Design",
http://www.ee.unsw.edu.au/~timm/pubs/02icc/published.pdf. Moors shows
that the Saltzer, Reed, and Clark argument for end-to-end placement is
both circular and inconsistent with the FTP example that is supposed to
demonstrate it. But the tres amigos of e2e were writing in 1981 when
network engineering was mostly a matter of intuition, so what do you
expect?
One of the more interesting unresolved questions about "End-to-End Args"
is why it was written in the first place. Some people see it as a salvo
in the ISO protocol wars, others as an attack in BBN's ARPANET, some as
an attempt to criss the divide between engineering and policy, and there
are probably other theories as well.
The Blumenthal and Clark "Brave New World" paper was very influential
because it lit the fire under Larry Lessig that got him storming around
about "protecting the Internet" from all the threats to stagnation and
freedom. There's a fairly clear path from Lessig's reaction to "Brave
New World" and the immoderate regulatory climate in the US today that's
so hostile to Internet progress.
RB
rick jones wrote:
>
> On Oct 23, 2009, at 3:58 AM, Jeroen Massar wrote:
>
>> Jaime Mateos wrote:
>>> Hi,
>>> I'm working on a project about the current challenges the Internet is
>>> presenting to the end-to-end argument. I'd be interested to know about
>>> any protocols, currently in use, that break the end-to-end principle
>>> and
>>> the context where they are used.
>>
>> Everything that needs an NAT helper, thus any protocol that embeds
>> addresses or ports, thus most games, everything that has a listening
>> port where the listening port is not on a public IP or firewalled away.
>
> Isn't the sense incorrect there? I always thought it was the NAT
> itself, and its need for helpers that was in opposition to the
> quasi-mythical end-to-end principle?
>
> rick jones
> Wisdom teeth are impacted, people are affected by the effects of events
>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From mbaer at cs.tu-berlin.de Fri Oct 23 22:46:05 2009
From: mbaer at cs.tu-berlin.de (=?ISO-8859-1?Q?Matthias_B=E4rwolff?=)
Date: Sat, 24 Oct 2009 07:46:05 +0200
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com>
<4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com>
<4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> <4AE22137.10909@reed.com>
<84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk>
Message-ID: <4AE2949D.5070200@cs.tu-berlin.de>
Lloyd Wood wrote:
>
> On 23 Oct 2009, at 22:33, David P. Reed wrote:
>> In particular: there was never an "end-to-end principle". So if you
>> get the title wrong, why should we trust you to get the details right?
>
> because "end-to-end argument principle" is appalling grammar. The word
> "principle" appears multiple times in the paper, including the
> abstract and conclusions.
The word "principle" appears *only* in the abstract, plus in the second
and the penultimate sentence of the 1984 paper. The content of the
paper, however, is very much about arguments (as in debate), not
principle (as in strict and not to argue with), maybe not even so much
about argument (as in "one logical conclusion to an irrefutable reasoning").
With all respect for the authors, we all know how abstracts are
typically written: It is often the very last thing on one's mind, even
though it should be the very first (although or possibly just because
written at the end of the process). Often, they are either totally
redundant (just repeating phrases from the content), or they exaggerate
things in a bid to draw the reader to the content. Rarely do they
capture precisely the essence of a paper.
An aside: I'd be interested to see the the 1981 version, and whether it
is much different from the 1984 one. Does anyone have it?
Matthias
--
Matthias B?rwolff
www.b?rwolff.de
From richard at bennett.com Fri Oct 23 23:17:03 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 24 Oct 2009 02:17:03 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE2949D.5070200@cs.tu-berlin.de>
References: <4AE184EE.5040800@tcd.ie> <4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk> <4AE1BBBF.2090109@reed.com> <4AE1CB96.3020203@dcrocker.net> <4AE1CEC5.4000306@reed.com> <4AE1D4E6.2010105@bbiw.net> <4AE1ED79.2010604@reed.com> <4AE22137.10909@reed.com> <84E34418-0098-485A-8E33-500498DF4067@surrey.ac.uk>
<4AE2949D.5070200@cs.tu-berlin.de>
Message-ID: <4AE29BDF.7020103@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/518d68b4/attachment.html
From Jon.Crowcroft at cl.cam.ac.uk Sat Oct 24 01:41:01 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sat, 24 Oct 2009 09:41:01 +0100
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu>
References: <20091023165835.1D4E66BE5F8@mercury.lcs.mit.edu>
Message-ID:
one of the problems is language evolution/erosion
for some people
an end-to-end _argument_
is an argument for everything
being in the end point
as opposed to the more
nuanced
meaning of the aforesaid paper(s)
in which it is a
set of dynamic debates
which set a tension
between whether you put something
in the end,
in the end,
or not
(i.e. in the intermediate).
the "argument" then is not a polemic
but a method or process (or dialectic)
that can and should be
dynamically reapplied
as technology and the environment
evolve.
In missive <20091023165835.1D4E66BE5F8 at mercury.lcs.mit.edu>, Noel Chia
ppa typed:
>> > From: Dave CROCKER
>>
>> > My sense of things is that the term is not actually defined all that
>> > concretely or consistently
>>
>>Sorry, I disagree. The original Saltzer/Clark/Reed paper does a pretty
>>good job, I think - as well as one can do with a broad architectural
>>concept, which is inherently not as susceptible to precise definition as,
>>say, an algorithm.
>>
>> > this has made it difficult to use the term constructively.
>>
>>No, people being bozos and not using the term _as it wss originally
>>defined_ are what has made its use problematic.
>>
>> Noel
cheers
jon
From william.allen.simpson at gmail.com Sat Oct 24 05:06:08 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Sat, 24 Oct 2009 08:06:08 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
Message-ID: <4AE2EDB0.3010406@gmail.com>
rick jones wrote:
> Perhaps he is referring to chips which provide TCP/Transport
> Segmentation Offload - aka TSO - the functionality that allows the stack
> to hand the chip a chunk of data > the MTU, along with the initial
> TCP/IP headers and the connection's on the wire MSS, and then have the
> chip otherwise statelessly segment that larger chunk of data into
> MSS-sized segments for transmission on the wire/fibre/etc.
>
It is indeed. Since the hardware driver is unaware of many things,
such as path MTU, this is one of its serious impediments.
Sure, there are measurements that show several percentage points less
CPU, but in most cases we're not CPU bound. I'm not sure what problem
it's solving, other than a checkbox to differentiate commodity products.
Worst of all, this stuff is all implemented in unmodifiable,
proprietary firmware.
> If that is the functionality of which he speaks, it is in virtually
> every contemporary 1GbE card I can think of (but my thoughts cannot span
> the entirety of the space I suspect). Also, virtually every 10G NIC out
> there offers the same functionality.
>
Gaah! I only knew about the Broadcom chips, as discussed on the NetBSD
lists a few years back, and didn't know this disease had spread.
> And if that upsets him, we better not tell him about the 10G NICs also
> doing receive offload... :)
>
I'd heard of it, but thought that was pretty uniformly rejected. Heck,
the most basic TCP decision points would be impossible to implement,
revise, or test.
> BTW, I do not believe that any router actually has TSO happen to TCP
> segments contained within the IP datagrams passing through it - although
Only recently trying to decipher the Linux stack, but it all appears to
go through the same queue, routed packets included. If the box receives
a jumbogram on one interface, it can be re-segmented out another, and
I've not found any support for PMTUD or ECN or anything.
> there have been issues in Linux with LRO (Large Receive Offload,
> distinct from General Receive Offload) when the system was acting as
> either a router or a bridge - because TSO doesn't happen in that path :)
>
Again, I'm not as familiar with Linux-only terminology. A quick Google
turns up "Generic Receive Offload", and that appears to be explicitly
designed to merge segments in routers, and re-segment out the other side:
http://lwn.net/Articles/311357/
I'm pretty sure this is contrary to the end-to-end [argument, principle,
what-have-you].... And covered by a passel of patents.
From dpreed at reed.com Sat Oct 24 07:12:24 2009
From: dpreed at reed.com (David P. Reed)
Date: Sat, 24 Oct 2009 10:12:24 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE27329.3040801@bennett.com>
References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com>
<4AE27329.3040801@bennett.com>
Message-ID: <4AE30B48.9090405@reed.com>
Since the moderator did not find a problem with Bennett's posting, I
will request his leave to address Bennett's ouvre and in particular this
particular posting in a more direct manner, since he has walked into
this *technical* forum with a variety of outrageous claims directed at
the motives of me and my co-authors.
On 10/23/2009 11:23 PM, Richard Bennett wrote:
> One of the more interesting unresolved questions about "End-to-End
> Args" is why it was written in the first place. Some people see it as
> a salvo in the ISO protocol wars, others as an attack in BBN's
> ARPANET, some as an attempt to criss the divide between engineering
> and policy, and there are probably other theories as well.
Richard Bennett spends a fair amount of his writing imputing motives to
people, and then using those motives to somehow impugn their credibility.
The above paragraph is such an example. (Please note that I am just
stating a fact about his writing style. You can read the paper he
submitted for lots of examples. He has also imputed that Vint Cerf and
Bob Kahn "stole" the ideas for the Internet from Pouzin without proper
credit.
Now I don't know if he can read the minds of Jerry Saltzer, Dave Clark,
or myself in writing the original paper. However the paragraph quoted
above is about the most ridiculous claim I have ever heard. We wrote
the paper as an attempt to contribute to the art of architecting the
Internet, as I believe most of the people on this list would
understand. However, Bennett has no shame. He does, however act as a
troll.
>
>
From dpreed at reed.com Sat Oct 24 07:34:14 2009
From: dpreed at reed.com (David P. Reed)
Date: Sat, 24 Oct 2009 10:34:14 -0400
Subject: [e2e] TCP offload (was part of Protocols breaking the end-to-end
argument)
In-Reply-To: <4AE2EDB0.3010406@gmail.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
<4AE2EDB0.3010406@gmail.com>
Message-ID: <4AE31066.8010109@reed.com>
Because I sense this thread might be interesting, and should be
separated from the trolling going on in the original thread, I changed
the title.
TCP offload is interesting. We actually addressed this kind of thing is
the "Active Networks" vs. end-to-end paper. Function placement at the
architectural level actually can be discussed with regard to "design
time" and "implementation time" versions of the arguments. For example,
if I am an "end host" but I do some of my functions on "attached support
processors" (excuse the "I" as metaphor for the main OS and CPU), that
may be quite clean architecturally - IF the communication between me and
the attached support processor is one that makes it act as part of
"me". So one could consider it part of the "end", even if it is in a
middlebox: the distinction is that it is under my sole control (so it
acts as a fully controlled module).
The end-to-end argument in the paper says that such acceleration can be
in the network, if indeed it merely accelerates a function that is in
all endpoints. However, the argument asks that we consider whether the
improvement overall is really worth it.
I leave it to the community of architects (not the chip designers, who
have a bias to believe that every "feature" is a differentiating
advantage) to decide whether the benefit of this particular thing is
really worth the potential inflexibility it creates - in particular the
risk that the chip will do the wrong thing on the forwarding path, and
the risk that the TCP spec will change in a way that makes the chip's
popularity a barrier to innovation.
It sounds as if there is a chance that, due to how one of the TOS chips
works, the portion of TCP that it implements is not strictly an "agent"
of the host TCP stack running on the host processor, but instead based
on "pattern recognition" that cannot be turned off. (I haven't read the
spec, so maybe it is more subtle than that).
That would result in a serious bug - if the chip is used by a low-level
forwarding path, perhaps an ethernet bridge or an IP routing layer, the
"optimization" would by accident be applied to TCP segments having
nothing to do with the host. This clearly makes using such chips in
general boxes like Linux boxes, that can perform ethernet bridging, IP
forwarding, etc. QUITE problematic! So perhaps they need to be marked
as *inappropriate* for general use. But that is because they really are
buggy for that use. (again, I haven't read the spec).
From perfgeek at mac.com Sat Oct 24 09:24:23 2009
From: perfgeek at mac.com (rick jones)
Date: Sat, 24 Oct 2009 09:24:23 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE2EDB0.3010406@gmail.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
<4AE2EDB0.3010406@gmail.com>
Message-ID: <84DEEF1B-057D-4C08-AE2B-EFB525A53BE5@mac.com>
On Oct 24, 2009, at 5:06 AM, William Allen Simpson wrote:
> rick jones wrote:
>> Perhaps he is referring to chips which provide TCP/Transport
>> Segmentation Offload - aka TSO - the functionality that allows the
>> stack to hand the chip a chunk of data > the MTU, along with the
>> initial TCP/IP headers and the connection's on the wire MSS, and
>> then have the chip otherwise statelessly segment that larger chunk
>> of data into MSS-sized segments for transmission on the wire/fibre/
>> etc.
> It is indeed. Since the hardware driver is unaware of many things,
> such as path MTU, this is one of its serious impediments.
WRT PathMTU, the implementations with which I am familiar have the
stack telling the NIC the on-the-wire size (what I tend to call the
effective MSS) to use on each "large send" where that effective MSS is
updated based on PathMTU information as/if it arrives.
> Sure, there are measurements that show several percentage points less
> CPU, but in most cases we're not CPU bound. I'm not sure what problem
> it's solving, other than a checkbox to differentiate commodity
> products.
When the functionality was introduced in the 1GbE NICs it was to allow
them to be driven at link-rate with the then-contemporary CPUs, not
only for easily dismissed (well, not IMO :) things like netperf
TCP_STREAM, but also for items customers actually did like file
transfers, or clustered database traffic, etc. (ie if you can't get
there with netperf, you ain't going to get there with FTP)
Now, this may be a place where my world starts to diverge from the
rest of the end2end community's - indeed many of my employer's
customers do things across the big-I Internet, but they do far more
across their corporate LANs and intranets. I can see where being CPU
bound talking across the big-I Internet is perhaps rare, but being CPU
bound when talking across the corporate 1 Gig LAN was not rare. And
essentially we have One Protocol to Rule Them All...
Yes, CPUs today are "faster" than at the dawn of 1 Gig Ethernet. We
are also at the dawn (perhaps a little past, depends I suppose on
one's deployment longitude) of 10 Gig Ethernet. Bless their hearts,
when a customer upgrades their network from one speed to the next,
they care little about Amdahl's Law etc and get quite agitated when
one cannot achieve link-rate on the next higher speed. Well, they
might give you a generation's worth of lee-way, but by the time the
second generation of the NIC arrives, their expectations are pretty
firm. If your solution cannot achieve link-rate, your solution is not
selected.
TSO and GRO, like Jumbo Frames, can be thought of as the inevitable
"inter-reaction" between customer expectations and a de jure network
MTU size that has remained unchanged since the dawn of Ethernet. Or,
put another way, we have begun treating the Ethernet MTU as damaged
and routed around it.
>> And if that upsets him, we better not tell him about the 10G NICs
>> also doing receive offload... :)
> I'd heard of it, but thought that was pretty uniformly rejected.
> Heck,
> the most basic TCP decision points would be impossible to implement,
> revise, or test.
"LRO" (multiple segment coalescing done in the chip and an uber frame
hitting the host with the intermediate headers stripped) has been
rejected in Linux-land in favor of GRO, which preserves the arriving
segment boundaries via some clever linking of buffers (and perhaps
some header-data split but I'm fuzzy there).
>> BTW, I do not believe that any router actually has TSO happen to
>> TCP segments contained within the IP datagrams passing through it -
>> although
>
> Only recently trying to decipher the Linux stack, but it all appears
> to
> go through the same queue, routed packets included. If the box
> receives
> a jumbogram on one interface, it can be re-segmented out another, and
> I've not found any support for PMTUD or ECN or anything.
>
>
>> there have been issues in Linux with LRO (Large Receive Offload,
>> distinct from General Receive Offload) when the system was acting
>> as either a router or a bridge - because TSO doesn't happen in that
>> path :)
> Again, I'm not as familiar with Linux-only terminology. A quick
> Google
> turns up "Generic Receive Offload", and that appears to be explicitly
> designed to merge segments in routers, and re-segment out the other
> side:
>
> http://lwn.net/Articles/311357/
>
> I'm pretty sure this is contrary to the end-to-end [argument,
> principle,
> what-have-you]....
You are supposed to be ignoring the code-path behind the curtain :)
rick jones
http://homepage.mac.com/perfgeek
From jnc at mercury.lcs.mit.edu Sat Oct 24 11:00:15 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 24 Oct 2009 14:00:15 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
> From: Richard Bennett
> The best discussion I've seen of function placement in a datagram
> network to this day is found in Louis Pouzin's mongraph on the CYCLADES
> network, _Cyclades Computer Network: Towards Layered Network
> Applications_, Elsevier Science Ltd (September 1982).
I'm not sure I'm totally on board with that "best" attribute, but the work of
Pouzin et al was an _extremely_ important step in the evolution of networking,
and often does't get the credit it deserves (e.g. one of the papers I read in
preparing to respond to this email didn't mention it, in reviewing the
philosophical development of the architecture of TCP/IP).
> Tim Moors' "A Critical Review of End-to-End Arguments in System
> Design", http://www.ee.unsw.edu.au/~timm/pubs/02icc/published.pdf.
A good and interesting paper; thanks for bring it to my attention. I do think
it goes off the beam in a couple of places, though.
For one, NATs became widespread mostly a result of flaws in the original
engineering (too small an address space) and architecture (too few namespaces,
leading to difficulty in supporting things like provider independence). NATs
are not inherently desirable, and would not, I think, have
evolved/proliferated had TCP/IP avoided those (in hindsight, now obvious)
mistakes.
For another, the current routing architecture has been driven much more by
factors such as technical hysteresis (both personnel familiarity with the
existing distributed computation model, as well as 'if it isn't broken, don't
fix it') and 'alligator' syndrome (as in 'when you're up to your
you-know-what in alligators [growing the network, in this case], you don't go
looking for more not-immediately-important fights').
Still, those are nits in the overall sweep of the paper.
> Moors shows that the Saltzer, Reed, and Clark argument for end-to-end
> placement is both circular and inconsistent with the FTP example that
> is supposed to demonstrate it.
I didn't see that at all.
> One of the more interesting unresolved questions about "End-to-End
> Args" is why it was written in the first place. Some people see it as a
> salvo in the ISO protocol wars, others as an attack in BBN's ARPANET,
> some as an attempt to criss the divide between engineering and policy
I don't know whether to be amused or outraged by this nonsense.
I will settle for observing that you probably haven't interacted much with
Jerry - because had you done so, it would have been utterly obvious to you
that overwhelmingly his most important motivation in writing the paper was
his deep commitment to improving the art of system architecture.
Dave Reed is here to defend himself, and as to Dave Clark, I would be prepared
to bet pretty much any stakes that he'd be in the front rank in acclaiming the
ARPANet as a huge step forward in information networking.
The reference to the "ISO protocol wars" is completely mystifying, as the
architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the
subset which gave TCP/IP the best 'run for their money') is basically
identical to that of TCP/IP (modulo disagreements on certain arcane points,
such as exactly what kind of abstract entities the names at the various levels
refer to - a subject wholly unrelated to the end-end debate).
Noel
From richard at bennett.com Sat Oct 24 12:54:22 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 24 Oct 2009 12:54:22 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID: <4AE35B6E.1080801@bennett.com>
Noel Chiappa wrote:
> > From: Richard Bennett
>
> > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end
> > placement is both circular and inconsistent with the FTP example that
> > is supposed to demonstrate it.
>
> I didn't see that at all.
>
Moors points out that TCP error detection and recovery is an end-system
function, but not really an endpoint function in the file transfer
example. The file transfer *application* is the endpoint, so placing the
error detection and recovery function in TCP is actually putting it in
an intermediate system level. This becomes clear when we recognize that
TCP is often implemented in hardware or in firmware running on a CPU
that lives on an interface card. The paper goes to great lengths to show
that host-based TCP is immune to problem induced at MIT by a bad 1822
interface card, but it was very common engineering practice in the
mid-80s to implement TCP on an interface card that had the same
vulnerability as the 1822 card. Excelan and Ungermann-Bass built these
systems and they were very popular. They designed in a competent level
of data integrity at the bus interface, so it wasn't necessary to rely
on software to detect bus problems. So it's at least ironic that the
end-to-end argument on the data integrity basis was mooted by practice
by the time the 1984 version of the paper was published.
Because the file transfer program doesn't do its own data integrity
checking but relies on TCP to do it, it's not really an example of
endpoint placement at all; in fact, it's a "partial implementation".
>
> > One of the more interesting unresolved questions about "End-to-End
> > Args" is why it was written in the first place. Some people see it as a
> > salvo in the ISO protocol wars, others as an attack in BBN's ARPANET,
> > some as an attempt to criss the divide between engineering and policy
>
> I don't know whether to be amused or outraged by this nonsense.
>
I don't know why this question should get anybody upset, it's just a
question about the context and motivation of the paper in the first
place. None of the authors was part of the inner circle of the Internet
protocol design at the time the paper was written, although Clark was
either the Chief Architect of the Internet or on his way to becoming
same. I would have expected Cerf and Kahn to write something explaining
the architectural decisions they made in adapting the framework to
their system, but their failure to do so meant someone else had to do
it. Why these three people and why this particular time? It's never been
explained.
> I will settle for observing that you probably haven't interacted much with
> Jerry - because had you done so, it would have been utterly obvious to you
> that overwhelmingly his most important motivation in writing the paper was
> his deep commitment to improving the art of system architecture.
>
> Dave Reed is here to defend himself, and as to Dave Clark, I would be prepared
> to bet pretty much any stakes that he'd be in the front rank in acclaiming the
> ARPANet as a huge step forward in information networking.
>
> The reference to the "ISO protocol wars" is completely mystifying, as the
> architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the
> subset which gave TCP/IP the best 'run for their money') is basically
> identical to that of TCP/IP (modulo disagreements on certain arcane points,
> such as exactly what kind of abstract entities the names at the various levels
> refer to - a subject wholly unrelated to the end-end debate).
The "ISO protocol wars" I am referring to took place within the context
of the ISO development community between the CLNP that the datagram
people wanted and CONS, the connection-oriented service that was
proposed by the European PTTs. CONS was an extension of the line of
development that went from ARPANET to X.25, which CLNP was on the line
that went from CYCLADES through DECnet. The naming and addressing logic
in CLNP and its predecessors was very different from TCP/IP but
consistent with these others. The reasons that ISO didn't succeed are
well-documented in John Day's "Patterns in Network Architecture."
Like it or not, Noel, there was a lot of friction between the Network
Working Group and BBN over the control BBN had over the ARPANET
protocols inside the IMP. The interesting problems of the day in
protocol design were all behind the curtain to the people who used the
ARPANET, and that's frustrating to engineers. Nobody disagrees that
ARPANET was a huge first step in packet switching; but by 1981, people
were well into the second step, and the closed implementation of the
lower three layers was a problem.
> Noel
>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From richard at bennett.com Sat Oct 24 13:01:41 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 24 Oct 2009 13:01:41 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE30B48.9090405@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4AE18C73.7000208@spaghetti.zurich.ibm.com>
<4AE27329.3040801@bennett.com> <4AE30B48.9090405@reed.com>
Message-ID: <4AE35D25.4000509@bennett.com>
Don't get so emotional David, it doesn't make you look good. I never
said that Cerf and Kahn stole CYCLADES without proper credit; I give
examples of the credit they did give in order to prove the line of
influence from CYCLADES to TCP/IP, and quoted Cerf on the help that
Gerard LeLann provided to the Stanford team. I note that *your* paper
doesn't cite Pouzin, which is something that certainly miffed at least
one of your co-authors; my sentence is something like "the E2E Args
authors didn't seem to have been aware of CYCLADES" which is based on a
failure to reference.
I think it's unfortunate that the Internet community was already trying
to erase Pouzin from history in 1981, when his contribution was so
monumental. Let's give credit where it's due.
And as I've said already, I think the question of motivation and timing
is interesting, and don't claim to know the answer. Seems like this is a
good place to ask the question is all.
RB
David P. Reed wrote:
> Since the moderator did not find a problem with Bennett's posting, I
> will request his leave to address Bennett's ouvre and in particular
> this particular posting in a more direct manner, since he has walked
> into this *technical* forum with a variety of outrageous claims
> directed at the motives of me and my co-authors.
>
> On 10/23/2009 11:23 PM, Richard Bennett wrote:
>> One of the more interesting unresolved questions about "End-to-End
>> Args" is why it was written in the first place. Some people see it as
>> a salvo in the ISO protocol wars, others as an attack in BBN's
>> ARPANET, some as an attempt to criss the divide between engineering
>> and policy, and there are probably other theories as well.
> Richard Bennett spends a fair amount of his writing imputing motives
> to people, and then using those motives to somehow impugn their
> credibility.
> The above paragraph is such an example. (Please note that I am just
> stating a fact about his writing style. You can read the paper he
> submitted for lots of examples. He has also imputed that Vint Cerf
> and Bob Kahn "stole" the ideas for the Internet from Pouzin without
> proper credit.
>
> Now I don't know if he can read the minds of Jerry Saltzer, Dave
> Clark, or myself in writing the original paper. However the
> paragraph quoted above is about the most ridiculous claim I have ever
> heard. We wrote the paper as an attempt to contribute to the art of
> architecting the Internet, as I believe most of the people on this
> list would understand. However, Bennett has no shame. He does,
> however act as a troll.
>>
>>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From dpreed at reed.com Sat Oct 24 15:39:28 2009
From: dpreed at reed.com (David P. Reed)
Date: Sat, 24 Oct 2009 18:39:28 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE35B6E.1080801@bennett.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com>
Message-ID: <4AE38220.7010202@reed.com>
I don't know why I waste my time explaining to Richard Bennett what he
misreads, but here goes:
On 10/24/2009 03:54 PM, Richard Bennett wrote:
>
>
> Noel Chiappa wrote:
>> > From: Richard Bennett
>>
>> > Moors shows that the Saltzer, Reed, and Clark argument for end-to-end
>> > placement is both circular and inconsistent with the FTP example that
>> > is supposed to demonstrate it.
>>
>> I didn't see that at all.
> Moors points out that TCP error detection and recovery is an
> end-system function, but not really an endpoint function in the file
> transfer example. The file transfer *application* is the endpoint, so
> placing the error detection and recovery function in TCP is actually
> putting it in an intermediate system level. This becomes clear when we
> recognize that TCP is often implemented in hardware or in firmware
> running on a CPU that lives on an interface card. The paper goes to
> great lengths to show that host-based TCP is immune to problem induced
> at MIT by a bad 1822 interface card, but it was very common
> engineering practice in the mid-80s to implement TCP on an interface
> card that had the same vulnerability as the 1822 card. Excelan and
> Ungermann-Bass built these systems and they were very popular. They
> designed in a competent level of data integrity at the bus interface,
> so it wasn't necessary to rely on software to detect bus problems. So
> it's at least ironic that the end-to-end argument on the data
> integrity basis was mooted by practice by the time the 1984 version of
> the paper was published.
>
> Because the file transfer program doesn't do its own data integrity
> checking but relies on TCP to do it, it's not really an example of
> endpoint placement at all; in fact, it's a "partial implementation".
>
OK. This is incredibly simple to understand. In the end-to-end
argument paper, we describe a program called "careful file transfer",
whose goal is to ensure that the file received is a proper copy of the
source. We use this "careful file transfer" example as a pedagogical
device.
The paper carefully does not claim that TCP or FTP over TCP satisfy the
end-to-end argument required for the function "careful file transfer".
There was a reason: FTP/TCP does not do so.
Now, RB claims that Moors's paper somehow says the argument is
inconsistent with the FTP example. Well, no. It is consistent with
the actual example we use, which is not FTP/TCP.
Bennett may have joined late this particular discussion. If so, he
missed my earlier posting that said that the end-to-end argument did not
say "TCP is best". It was not a defense of TCP at all (unless you
accept his mind-reading of the authors' intent to somehow write the
paper to be part of some fight that Bennett imagines was going on).
The end-to-end argument paper was not a paper about TCP or IP or any
particular implementation of any protocol, except insofar as it was
inspired by architectural discussions in the design, and was cited quite
frequently by IETF architects later as they considered designs happening
afterwards. It was about a way to think about architectural questions
- one that was used frequently and heavily in the original TCP and IP
design process, and as noted in the paper, in a number of other
processes we were aware of and had been involved in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/47ab6aab/attachment.html
From dpreed at reed.com Sat Oct 24 15:45:23 2009
From: dpreed at reed.com (David P. Reed)
Date: Sat, 24 Oct 2009 18:45:23 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE35B6E.1080801@bennett.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com>
Message-ID: <4AE38383.2030603@reed.com>
I can't resist commenting on this:
On 10/24/2009 03:54 PM, Richard Bennett wrote:
> Like it or not, Noel, there was a lot of friction between the Network
> Working Group and BBN over the control BBN had over the ARPANET
> protocols inside the IMP. The interesting problems of the day in
> protocol design were all behind the curtain to the people who used the
> ARPANET, and that's frustrating to engineers. Nobody disagrees that
> ARPANET was a huge first step in packet switching; but by 1981, people
> were well into the second step, and the closed implementation of the
> lower three layers was a problem.
This is both irrelevant, and bizarre. Again, Bennett focuses on imputed
motivations to impugn people's professional actions. There was no
friction that mattered - protocols were not designed to carry out
"anger". Since Bennett was not there, I can only assume he is talking
to some very angry people who were there.
In any case, lecturing Noel Chiappa, who has more experience with the
Internet and networking by far seems to be an odd thing to try to do.
I'd suggest people look at Bennett's resume at
http://www.bennett.com/resume.pdf. You might find his claims that he
was responsible for some of the most important IEEE protocols a bit
interesting. I take no position on the claims.
From richard at bennett.com Sat Oct 24 16:46:42 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 24 Oct 2009 16:46:42 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE38383.2030603@reed.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com> <4AE38383.2030603@reed.com>
Message-ID: <4AE391E2.80503@bennett.com>
As usual, an attempt to discuss ideas in a forum inhabited by David Reed
quickly becomes an exercise in scurrilous personal attack; my role in
shaping IEEE 802 standards from 1984 to the present is a matter of
historical record than be discovered by any conscientious person in a
matter of minutes.
On the subject of BBN's standing in the early Internet community, I'll
simply note that the term "Big Bad Neighbor" was a common usage that I
did not coin myself, and Steve Crocker's comments in RFC 1 had a
well-understood subtext.
RB
David P. Reed wrote:
> I can't resist commenting on this:
>
> On 10/24/2009 03:54 PM, Richard Bennett wrote:
>> Like it or not, Noel, there was a lot of friction between the Network
>> Working Group and BBN over the control BBN had over the ARPANET
>> protocols inside the IMP. The interesting problems of the day in
>> protocol design were all behind the curtain to the people who used
>> the ARPANET, and that's frustrating to engineers. Nobody disagrees
>> that ARPANET was a huge first step in packet switching; but by 1981,
>> people were well into the second step, and the closed implementation
>> of the lower three layers was a problem.
>
> This is both irrelevant, and bizarre. Again, Bennett focuses on
> imputed motivations to impugn people's professional actions. There
> was no friction that mattered - protocols were not designed to carry
> out "anger". Since Bennett was not there, I can only assume he is
> talking to some very angry people who were there.
>
> In any case, lecturing Noel Chiappa, who has more experience with the
> Internet and networking by far seems to be an odd thing to try to do.
> I'd suggest people look at Bennett's resume at
> http://www.bennett.com/resume.pdf. You might find his claims that he
> was responsible for some of the most important IEEE protocols a bit
> interesting. I take no position on the claims.
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From richard at bennett.com Sat Oct 24 16:50:50 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 24 Oct 2009 16:50:50 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE38220.7010202@reed.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com> <4AE38220.7010202@reed.com>
Message-ID: <4AE392DA.2090203@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091024/150d45ee/attachment-0001.html
From dga+ at cs.cmu.edu Sat Oct 24 18:56:13 2009
From: dga+ at cs.cmu.edu (David Andersen)
Date: Sat, 24 Oct 2009 21:56:13 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE392DA.2090203@bennett.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com> <4AE38220.7010202@reed.com>
<4AE392DA.2090203@bennett.com>
Message-ID: <4F8DBE3C-E5D5-41D8-9C75-832EFB778A12@cs.cmu.edu>
Hi, Richard, and everyone -
Having read the e2e argument paper a number of times (I, like half the
networking faculty I know, use it as a discussion point in my graduate
networks and distributed systems courses), I think it's worth taking a
step back from this debate a bit, which has clearly extended beyond
the realm of the purely technical.
(The preceding paragraph may be taken, correctly, as a doubtless
unsuccessful plea to abandon the ad hominem attacks on all sides of
this argument in favor of what is, actually, a fun discussion.)
In particular, I believe that your argument is taking a (perhaps
deliberately) overly strong interpretation of what was actually
written in the e2e paper, which makes a somewhat subtle argument that
is devoid of absolute black and white insistence about the placement
of functionality. This seems like a very common misinterpretation --
it even shows up in the subject of this thread: "breaking" the end-to-
end argument, as if it was a law writ in stone by the hand of the
Internet Gods.
DPR's representation of the e2e argument in this discussion is
entirely in keeping with the text of the paper, which included no
mention of TCP providing reliability. In fact, it's become
increasingly clear over time that a careful file transfer system -- or
a careful storage system -- probably has to implement exactly the type
of strong error checking alluded to in the e2e paper. See, for
instance, a lot of recent work on long-term digital data preservation,
or, more commercially, the content-hash based storage systems now
provided by major vendors such as EMC.
TCP offload does not particularly seem to disagree with the point of
the e2e argument, as it was stated.
"It would be too simplistic to conclude that the lower levels
should play no part in obtaining reliability."
and the argument in the paper makes it very clear that there are
legitimate performance reasons for performing functions -- even
duplicating them -- at lower levels; one should simply make such
optimizations with full awareness of the consequences. Offload is a
great example: It's a very useful performance enhancement with
today's 10GE networks, and it may cause you some difficulties if you
want to take advantage of later enhancements to TCP. It's an
engineering tradeoff, pure and simple, which is all the "argument" is
about. So are 802.11 retransmissions, with which you're undoubtedly
familiar. Great, needed performance optimization -- they're an
excellent illustration of the "when you _should_ use the middle"
aspect of the paper.
-Dave Andersen
On Oct 24, 2009, at 7:50 PM, Richard Bennett wrote:
> There's no doubt about the fact that Saltzer was and still is
> regarded as one of the brightest lights in the system architecture
> firmament, and that in particular his seminal paper on naming and
> addressing was one of the most cogent pieces of its kind ever
> written. It's unfortunate that the structure of Saltzer's thinking
> isn't reflected in the organization of Internet protocols, naming,
> and addressing and that he wasn't able to pass his brilliance along
> to all of his students.
>
> RB
>
> David P. Reed wrote:
>> I don't know why I waste my time explaining to Richard Bennett what
>> he misreads, but here goes:
>>
>> On 10/24/2009 03:54 PM, Richard Bennett wrote:
>>>
>>>
>>> Noel Chiappa wrote:
>>>> > From: Richard Bennett
>>>>
>>>> > Moors shows that the Saltzer, Reed, and Clark argument for
>>>> end-to-end
>>>> > placement is both circular and inconsistent with the FTP
>>>> example that
>>>> > is supposed to demonstrate it.
>>>>
>>>> I didn't see that at all.
>>>>
>>> Moors points out that TCP error detection and recovery is an end-
>>> system function, but not really an endpoint function in the file
>>> transfer example. The file transfer *application* is the endpoint,
>>> so placing the error detection and recovery function in TCP is
>>> actually putting it in an intermediate system level. This becomes
>>> clear when we recognize that TCP is often implemented in hardware
>>> or in firmware running on a CPU that lives on an interface card.
>>> The paper goes to great lengths to show that host-based TCP is
>>> immune to problem induced at MIT by a bad 1822 interface card, but
>>> it was very common engineering practice in the mid-80s to
>>> implement TCP on an interface card that had the same vulnerability
>>> as the 1822 card. Excelan and Ungermann-Bass built these systems
>>> and they were very popular. They designed in a competent level of
>>> data integrity at the bus interface, so it wasn't necessary to
>>> rely on software to detect bus problems. So it's at least ironic
>>> that the end-to-end argument on the data integrity basis was
>>> mooted by practice by the time the 1984 version of the paper was
>>> published.
>>>
>>> Because the file transfer program doesn't do its own data
>>> integrity checking but relies on TCP to do it, it's not really an
>>> example of endpoint placement at all; in fact, it's a "partial
>>> implementation".
>>>
>> OK. This is incredibly simple to understand. In the end-to-end
>> argument paper, we describe a program called "careful file
>> transfer", whose goal is to ensure that the file received is a
>> proper copy of the source. We use this "careful file transfer"
>> example as a pedagogical device.
>>
>> The paper carefully does not claim that TCP or FTP over TCP satisfy
>> the end-to-end argument required for the function "careful file
>> transfer". There was a reason: FTP/TCP does not do so.
>>
>> Now, RB claims that Moors's paper somehow says the argument is
>> inconsistent with the FTP example. Well, no. It is consistent
>> with the actual example we use, which is not FTP/TCP.
>>
>> Bennett may have joined late this particular discussion. If so, he
>> missed my earlier posting that said that the end-to-end argument
>> did not say "TCP is best". It was not a defense of TCP at all
>> (unless you accept his mind-reading of the authors' intent to
>> somehow write the paper to be part of some fight that Bennett
>> imagines was going on).
>>
>> The end-to-end argument paper was not a paper about TCP or IP or
>> any particular implementation of any protocol, except insofar as it
>> was inspired by architectural discussions in the design, and was
>> cited quite frequently by IETF architects later as they considered
>> designs happening afterwards. It was about a way to think about
>> architectural questions - one that was used frequently and heavily
>> in the original TCP and IP design process, and as noted in the
>> paper, in a number of other processes we were aware of and had been
>> involved in.
>>
>>
>
> --
> Richard Bennett
> Research Fellow
> Information Technology and Innovation Foundation
> Washington, DC
>
From day at std.com Sat Oct 24 19:16:35 2009
From: day at std.com (John Day)
Date: Sat, 24 Oct 2009 22:16:35 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID:
>
>
>The reference to the "ISO protocol wars" is completely mystifying, as the
>architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the
>subset which gave TCP/IP the best 'run for their money') is basically
>identical to that of TCP/IP (modulo disagreements on certain arcane points,
>such as exactly what kind of abstract entities the names at the various levels
>refer to - a subject wholly unrelated to the end-end debate).
Cmon Noel, you know better than that. That was never what the
protocol wars were about.
It was not a war between CLNP/TP4 and TCP/IP, but a war between
(CLNP/TP4; TCP/IP) and X.25. The argument at the time by the PTTs
was that a Transport Protocol was unnecessary. Our argument, of
course, was that it was absolutely necessary. This was the big
argument from about 1976 to 1985. This is primarily what the
end-to-end paper discusses and tries to create a "higher moral
ground" by creating a more general (and hence more fundamental)
principle to base the debate on.
It was only later that the unwashed in the IETF turned it into a CLNP
vs IP war.
Take care,
John
From jnc at mercury.lcs.mit.edu Sat Oct 24 20:20:10 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 24 Oct 2009 23:20:10 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu>
Wow, you all have been busy. I'll have to get to some tomorrow, but this one
for now...
> From: John Day
>> The reference to the "ISO protocol wars" is completely mystifying, as
>> the architecture of the ISO stack (at least, the CLNP/TP4 flavour,
>> which was the subset which gave TCP/IP the best 'run for their money')
>> is basically dentical to that of TCP/IP
> Cmon Noel, you know better than that. That was never what the protocol
> wars were about.
>From where you were sitting, perhaps. My view was from a somewhat different
locations... :-) Seriously, though, the only protocol war I saw involving ISO
was the TCP/IP <-> ISO one - which is covered at some length in Abbabte's
excellent book, IIRC.
> It was not a war between CLNP/TP4 and TCP/IP, but a war between
> (CLNP/TP4; TCP/IP) and X.25.
Yes, but even at the time, to some of us that one had all the suspense of the
First Zulu War - gee, which is better, spears or repeating rifles? Doesn't
take a surfeit of brain cells to call that one..
> The argument at the time by the PTTs was that a Transport Protocol was
> unnecessary. Our argument, of course, was that it was absolutely
> necessary. This was the big argument from about 1976 to 1985. This is
> primarily what the end-to-end paper discusses
Yeah, but the reason TCP/IP clobbered X.25 had not much, I feel pretty sure,
to do with the inherent fundamentals of virtual circuits versus datagrams.
To me, the whole X.25 world was badly crippled by the whole X.75 (I think it
was X.75 - you can correct me if I've mis-remembered) mess that you had to use
if you wanted to set up a VC that spanned a number of providers. TCP/IP and
CLNP/TP4 (hereinafter, 'The Datagrams') never had to deal with that - in large
part because they were designed from the get-go to span multiple providers as
easily as they spanned a single one. My perception is that X.75 happened, in
large part, because it was an add-on to a legacy, X.25, which was designed for
single-provider networks. Of course, one could say that that was inherent,
because 'of course' to span multiple provider networks you'd have to a
mechanism to connect VC's together, but I'm not so sure; it should have been
possible to have a single unified VC 'network' that spanned multiple providers
- but of course the internal protocols (for acknowledgement, etc) would have
had to have been standardized, so they could operate on an inter-provider
basis.
But to me even that wasn't even the biggest handicap for X.25. The Datagrams
were set up pretty much from the get-go to work across a range of
technologies, including local area networks - and I claim it was the
Datagrams' friendliness to LANs which was the real 'killer app' in the X.25
<-> Datagram war. Of course, one could say that again, this was 'inherent' in
the architectures - but again, I'm not so sure; had a VC protocol been
designed _from the start_ to work well across a variety of media, including
LANs, it would probably have been considerably more LAN-friendly. It was the
'boat anchor' of the pre-LAN design of X.25, which the PTTs/etc couldn't or
wouldn't discard (because of installed base, existing software, and brain,
code, etc), that was the real killer of the X.25 dinosaurs in a world of LAN
mammals.
So I don't think X.25 vs The Datagrams was really a 'fair' test of the
fundamental pros and cons of VCs and datagrams: X.25 versus The Datagrams was
more like a rusty, bent, dull assegai versus the latest AR-15 - hardly a fair
test of the fundamentals.
> tries to create a "higher moral ground" by creating a more general
> (and hence more fundamental) principle to base the debate on.
Maybe my brain is fading, but my memory is that the trio were more interested
in a design philosophy framework for designing protocols in a basically
datagram environment; bringing more firepower to the VC/datagram debate was
not at all of much interest.
Again, to us, at the time, VC's had all the interest of rotationally
optimizing assemblers - clearly a technology which the march of improvement
had overtaken.
> It was only later that the unwashed in the IETF turned it into a CLNP
> vs IP war.
Read Abbate; TCP/IP versus CLNP/TP4 was a real set-to. As a TCP/IP backer, I
was far more worried about CLNP/TP4 than I ever was about X.25, which was
clearly a rusty assegai in a world of repeating rifles.
Unwashedly yours, :-)
Noel
From day at std.com Sat Oct 24 20:31:12 2009
From: day at std.com (John Day)
Date: Sat, 24 Oct 2009 23:31:12 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID:
>
>
>The reference to the "ISO protocol wars" is completely mystifying, as the
>architecture of the ISO stack (at least, the CLNP/TP4 flavour, which was the
>subset which gave TCP/IP the best 'run for their money') is basically
>identical to that of TCP/IP (modulo disagreements on certain arcane points,
>such as exactly what kind of abstract entities the names at the various levels
>refer to - a subject wholly unrelated to the end-end debate).
And to add to my previous note, CLNP didn't even exist when the e2e
paer was written.
From day at std.com Sat Oct 24 20:48:00 2009
From: day at std.com (John Day)
Date: Sat, 24 Oct 2009 23:48:00 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu>
References: <20091025032010.3B6B56BE5DD@mercury.lcs.mit.edu>
Message-ID:
>
>
>Read Abbate; TCP/IP versus CLNP/TP4 was a real set-to. As a TCP/IP backer, I
>was far more worried about CLNP/TP4 than I ever was about X.25, which was
>clearly a rusty assegai in a world of repeating rifles.
Read Abbate? You must be kidding. Why would I use 3rd hand sources?
You seem to forget, I was there. Starting with getting datagrams in
the first X.25 Recommendations (1976) thru the fight to get
connectionless into OSI. The debates around the IONL, getting CLNP
done, ensuring that it named the node so it would be a true Internet
protocol rather than a subnet protocol masquerading as an Internet
protocol.
As I said before, in 1982 there was no CLNP. In fact, TP4 didn't
exist either accept as a revised draft of INWG 96/ CYCLADES TS. The
connectionless addendum to ISO Reference Model wouldn't even be
approved as a draft for another year.
It seems that you and Abbate have been looking in the wrong end of
the telescope.
It would be a little hard for the e2e paper in 1982 to be about the
CLNP/TP4 vs TCP/IP debate if half the debate didn't exist.
> Unwashedly yours, :-)
>
> Noel
From jnc at mercury.lcs.mit.edu Sat Oct 24 20:59:04 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 24 Oct 2009 23:59:04 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
> From: John Day
> It would be a little hard for the e2e paper in 1982 to be about the
> CLNP/TP4 vs TCP/IP debate if half the debate didn't exist.
Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate'
(competition would be more accurate, I think). You seem to be conflating my
comments on two entirely separate points.
One was that for _some_ of us, the only 'ISO protocol war' we saw was the
CLNP/TP4 vs TCP/IP competition.
The other was that the E2E paper was not principally intended as firepower in
the TCP/IP vs X.25 debate, but rather was more intended to be exactly what
the passage of time has shown it to be - a contemplation of the underlying
fundamentals of functionality placement, one which would be of lasting value.
Noel
From william.allen.simpson at gmail.com Sun Oct 25 01:29:30 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Sun, 25 Oct 2009 04:29:30 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
Message-ID: <4AE40C6A.4060608@gmail.com>
Noel Chiappa wrote:
> One was that for _some_ of us, the only 'ISO protocol war' we saw was the
> CLNP/TP4 vs TCP/IP competition.
>
As an implementor during that period, I have to agree with Noel.
Back in the late '70s, we used X.25 for transmission because that's the
only thing that AT&T (via Telenet, with an 'e') would sell us. For
satellite data to move from field stations, as a practical matter we
were constrained by availability.
Just as weather data only came in 5-bit baudot coding. I programmed a
dedicated Alpha Micro (in reality, a minicomputer) to translate to 7-bit
ASCII. Then, to move it from the Alpha Micro to the Perkin-Elmer
Interdata 7/16, I used IBM bisync.
Before I'd ever heard of TCP/IP, I simply rolled my own "higher level"
packet format, to have a commonality over both X.25 and bisync. But it
was clear that had to have its own checksum. Folks seem to forget that
I-O buses were very unreliable. Corrupted data and dropped interrupts
were common. An independent transmission layer was crucial.
As I've mentioned recently, it wasn't until later that Merit decided to
implement TCP/IP. Remember, Merit had its own protocol stack as far
back as the '60s. ARPA was a relative late-comer around here....
It wasn't until CLNP that I ever perceived a 'war' (or competition). To
me, it was always apparent that the war wasn't with the protocols per
se, but rather the corporate entities that wanted to control pricing.
When I worked on Michigan's NSFnet bid, we took the money from state
budget line items that were using ISO protocols. To the politicians,
the potential savings over dedicated telco lines were a big plus. We
were still in the aftermath of the Reagan Recession.
And that was another element that is often overlooked. I know this is
less relevant outside the US, but the ISO corporate proponents were
primarily Republicans. The NSFnet proponents were primarily Democrats,
who were very interested in competition, cost savings, and leveling the
playing field.
> The other was that the E2E paper was not principally intended as firepower in
> the TCP/IP vs X.25 debate, but rather was more intended to be exactly what
> the passage of time has shown it to be - a contemplation of the underlying
> fundamentals of functionality placement, one which would be of lasting value.
>
Admittedly, I didn't read the paper until much later, so it had little
influence on my thinking. I vaguely remember a "well, duh" reaction, as
surely every implementor in the field already knew from experience.
But it has continued as an enduring touchstone to help explain these
fundamentals to successive generations.
From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 02:40:00 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sun, 25 Oct 2009 09:40:00 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID:
This is exactly right -
UCL were very much at the
"centre" of this at the turning point
(turning of NCP and on TCP/IP) and relaying from the new
internet world to/from the X.25 (and other) worlds -
The CLNP/TP4 paer of the ISO thing came to a small
degree from the DEC
(whose ideas show up again later in
TCP congestion control and later still in ECN)
which was a computer science approach to networking,
not telco at all.
The "war" was between telco
(connection oriented, reliable, ordered)
and computer science
(connectionless, best effort)
on the one hand
1. Sheer complicatedness of X.25
(both on paper and in reality)
made it hard to get right,
and the lack of losses on newer links (LANs) +
X.25 interpretations and implmentations'
failure to mask dynamic routing from transport,
and therefore from applications,
meant it was no longer justifiable to build
such complicated networks
which were also getting cheaper, albeit slowly.
on the other
2. Increase in end system capability
(e.g. mini computers like PDPs and LSIs,
and shortly after that, workstations)
meant, contrariwise,
the end system effort in TCP was justifiable.
likewise
3.
A little too late, some smart switch people build
x.25 systems that did VC on the edge,
but datagrams within and went fast,
but missed the curve (e.g. netcom switches).
Some of those people showed up again doing ATM
(e.g. ipsilon), understanding a VC service, but
internal dynamics with pnni etc might work - again
a little too late (and cell switching didn't have the
switch speed up/cost reduction they needed to beat routers)
TP4 (which my colleagues did experiments with)
was a neat piece of design, but has nothing much
to do with any of the main protocol wars ...
The other war story people might be getting confused by
when mentioning CLNP is the IPng NSAP/CLNP fiasco...
again not part of the e2e arguments part of ISO v. DARPA
but its own later skirmish between newer players.
To be strictly fair then,
while the bogey man in many a tee-shirt slogan was ISO,
it was the ITU (or CCITT as was) and the
telco mind set that was connection oriented networking
(with reliable link and network service)
specifically that was the focus of that "war"
or as I prefer to see it, a debate that played out
in markets and in operations -
Everyone has their own particular
turning point tale I'm sure,
but when we built the "shoestring"
IP service for UK academics,
this was a clear point for me that
we were able to make the
particular end2end choice visible
Around that time too,
various governments turned off their default
GOSIP (government OSI procurement) policies...
Much has flowed over many bridges since then:-)
A sad recent error has been
EU statements that everyone doing
next gen internet research should be
trying to converge on IPv6, but
that's a whole other rant...
cheers
j.
In missive , John Day typed:
>>It was not a war between CLNP/TP4 and TCP/IP, but a war between
>>(CLNP/TP4; TCP/IP) and X.25. The argument at the time by the PTTs
>>was that a Transport Protocol was unnecessary. Our argument, of
>>course, was that it was absolutely necessary. This was the big
>>argument from about 1976 to 1985. This is primarily what the
>>end-to-end paper discusses and tries to create a "higher moral
>>ground" by creating a more general (and hence more fundamental)
>>principle to base the debate on.
>>
>>It was only later that the unwashed in the IETF turned it into a CLNP
>>vs IP war.
>>
>>Take care,
>>John
cheers
jon
From day at std.com Sun Oct 25 04:55:57 2009
From: day at std.com (John Day)
Date: Sun, 25 Oct 2009 07:55:57 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
Message-ID:
At 23:59 -0400 2009/10/24, Noel Chiappa wrote:
> > From: John Day
>
> > It would be a little hard for the e2e paper in 1982 to be about the
> > CLNP/TP4 vs TCP/IP debate if half the debate didn't exist.
>
>Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate'
>(competition would be more accurate, I think). You seem to be conflating my
>comments on two entirely separate points.
No, you are the one who is conflating. The original point that I
made was about the context in which the e2e paper was written.What
was happening leading up to it.
>
>One was that for _some_ of us, the only 'ISO protocol war' we saw was the
>CLNP/TP4 vs TCP/IP competition.
This may be how it appeared in your corner of the world and when you
appeared in the discussion. By the time you got to MIT, this had
been going on for some time.
The protocol wars began in 1975 (or thereabouts) when we learned that
CCITT was developing X.25 and we tried to get datagrams put it into
it.
In fact, the TCP vs "TP4", i.e. CYCLADES TS, debate had been over for
4 years at that point. THAT debate had been carried out between 1974
and late 1977 in IFIP WG6.1 (INWG) where several Transport protocols
(not just those two) were discussed and analyzed. WG6.1 was managing
at least a couple of meetings a year at that time. There were many
participants from the US (APRANet/Internet) and Europe. The result
was INWG96 published at Danthine's conference in early 1978. As far
as we were concerned that ended the transport protocol discussion.
(Note that INWG 96 was authored by people from all sides of the
discussion: Cerf (Internet), MacKenzie (Internet), Scantlebury
(NPL), and Zimmermann (INRIA). As far as we were concerned there
never was a TCP/TP4 war, that issue was resolved before the standards
battles started in earnest.
Of course, now we know that neither was the best choice and that
delta-t was far superior to both.
As far as the "IP" discussion, we were pretty happy with that. The
only things we knew we needed to do for a world wide protocol was a
bigger address field and fix the problem that had arisen in 1972 with
Tinker AFB. We needed to name the node rather than the interface.
No one saw this as a big deal. XNS, CYCLADES, DECNet, EUNet had all
done that. (I always contend that the ARPANET didn't so much get it
wrong as we had a lot of other things to worry about and it was
first.)
This is why I was so shocked when the IETF refused to name the node
in 1992. We had known about the issue for 20 years. Everyone else
had by then fixed it. That was when it became clear that the IETF
had become more a craft guild than an engineering group and relied
more stock in tradition. Actually, it had begun before that but as
they say the third time is the charm.
But again here we were still to attached to the beads-on-a-string
model that we thought we had refuted. There was a further
simplification that we couldn't see at that point.
>
>The other was that the E2E paper was not principally intended as firepower in
>the TCP/IP vs X.25 debate, but rather was more intended to be exactly what
>the passage of time has shown it to be - a contemplation of the underlying
>fundamentals of functionality placement, one which would be of lasting value.
It certainly spends a lot of space arguing that point. In fact, in
the period leading up to its publication what other issue of what to
put in the network vs the hosts was being debated? As I said, I have
always seen the e2e paper as an attempt to create a more general
principle to refute that hop-by-hop error control could supplant e2e
error control. And by having a more general principle that when
other things were proposed for "in the network" there would be
something we could point to.
I am afraid that your (and Abbate's) perspective on what game was
afoot was very narrow and taken out of context with the war as a
whole.
From dpreed at reed.com Sun Oct 25 05:16:03 2009
From: dpreed at reed.com (David P. Reed)
Date: Sun, 25 Oct 2009 08:16:03 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
Message-ID: <4AE44183.80908@reed.com>
On 10/24/2009 11:59 PM, Noel Chiappa wrote:
> > From: John Day
>
> > It would be a little hard for the e2e paper in 1982 to be about the
> > CLNP/TP4 vs TCP/IP debate if half the debate didn't exist.
>
> Umm, I didn't say that the E2E paper was about the CLNP/TP4 vs TCP/IP 'debate'
>
The end-to-end paper was not written to be a part of any war
whatsoever. I say that with knowledge of all of the 3 co-authors'
intents and motivations.
I *now* am beginning to understand what mentality seems to be behind
Bennett's informants' views of history.
It's an oddly American cultural thing to identify evolutionary and
economic competitions as "wars". We have the "war on drugs", for
example. Somehow the "wars" become ends in themselves: winnning vs. losing.
But studying the competitions rarely provides insight into real issues.
Did the Battle of Gettysburg really tell us anything about either the
causes: an economy based on human slavery and "free market" ideals (the
American plantation south) vs. an economy based on industrialization,
internal market growth, and protectionist/imperialist approaches (the
American northeast)? (who won that battle didn't even stop the
argument...) Did the Battle of Gettysburg predict the creation of "Jim
Crow laws"? Did it prevent them?
I do remember a wide variety of battles about elements of networking,
including implementations of architectures. I briefly was involved in
the "token ring" vs. "bus" argument about physical infrastructure for
LANs - not as an advocate of either side - and I found it completely
bizarre. The idea on the "token ring" side was that somehow its
puissant "quality of service" would make the end-to-end communications
work, while the "unreliable" CSMA/CD would never be "carrier grade".
Bushwah - and I gently pointed that out in my portion of the original
paper I wrote about LANs with Clark and Pogran for IEEE Proceedings:
LANs would be parts of internets, and the QoS properties of a single LAN
would not transcend that LAN's scope.
That argument was an implied end-to-end argument: if you want to get a
specific service quality goal satisfied, putting the implementation of
that function in (every part of every one of the) subnetworks is not a
good design.
However, one can imagine achieving it that way. The resulting
architecture would be very inflexible, and costly to all of those who
*don't* need that particular extreme service quality goal. It would,
for example, make it hard to migrate the path of any communication while
it is happening.
In any case, the rather silly battle over CSMA/CD vs. token-controlled
access was pretty meaningless in the context of any kind of
internetworking: PUP or TCP or even the Cyclades thing.
But the "QoS" logic of that day pervades the debate even now. It's so
easy for those who don't build networks to wave their hands and say that
(for example) Verizon can provide QoS on the Internet, when what is
meant is that Verizon provides some latency control on *it's small
segment of the path* to all interesting endpoints.
This is a rhetorical device called synecdoche - in which the attributes
of a part are assumed to carry through to the whole. The idea that
Verizon can create QoS for the Internet by creating QoS for its part is
a logical fallacy. But it is one that humans continue to fall prey to.
So to summarize this longer diversion: the war between token ring and
bus-Ethernet teaches us little, and subsequent success of Ethernet as a
term teaches us very little about architecture: in fact, by shrinking
the collision domain to a hub, and then later replacing it with a switch
in the core, the Ethernet has moved towards the deterministic arbitrated
structure of the token ring, along with the manageability of the
"star-shaped" ring concept that Saltzer promoted as the topology.
So let's not study wars and battles. Let's study architectural
principles and their application.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/63404022/attachment.html
From dpreed at reed.com Sun Oct 25 05:43:24 2009
From: dpreed at reed.com (David P. Reed)
Date: Sun, 25 Oct 2009 08:43:24 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
Message-ID: <4AE447EC.7010301@reed.com>
On 10/25/2009 07:55 AM, John Day wrote:
>> The other was that the E2E paper was not principally intended as
>> firepower in
>> the TCP/IP vs X.25 debate, but rather was more intended to be exactly
>> what
>> the passage of time has shown it to be - a contemplation of the
>> underlying
>> fundamentals of functionality placement, one which would be of
>> lasting value.
>
> It certainly spends a lot of space arguing that point. In fact, in
> the period leading up to its publication what other issue of what to
> put in the network vs the hosts was being debated?
I always find the logic of this sort amazing: in my rhetoric class it
was called "post hoc, ergo propter hoc" argumentation. That is:
because X happened and it appeared to support Y, then Y was the reason X
happened. ("this was the result, therefore this was the reason")
John Day asks the question "what other issue" to replace actual
exploration. Since there have been numerous times in the past when he
could have just asked Jerry, Dave, or me, yet he persists in his belief,
perhaps he has some reason to imply that we would not tell him why we
wrote the paper. In fact, we have made a variety of statements as to
why we wrote it, in informal but public places. Yet he holds onto a belief.
Now in some circles the desire to hold onto a belief about others'
actions and motivations despite overwhelming evidence to the contrary is
understood to come close to that of conspiracy theorists. I don't
understand Day's obsession with this point. Since it has infected
Richard Bennett's writings, and is being repeated to the FCC in policy
debates supported by his "think tank" employer, it probably should be
recognized for what it is: a false belief.
> As I said, I have always seen the e2e paper as an attempt to create a
> more general principle to refute that hop-by-hop error control could
> supplant e2e error control. And by having a more general principle
> that when other things were proposed for "in the network" there would
> be something we could point to.
>
> I am afraid that your (and Abbate's) perspective on what game was
> afoot was very narrow and taken out of context with the war as a whole.
>
From mateosj at tcd.ie Sun Oct 25 06:00:12 2009
From: mateosj at tcd.ie (Jaime Mateos)
Date: Sun, 25 Oct 2009 13:00:12 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID: <4AE44BDC.2050704@tcd.ie>
Jon Crowcroft wrote:
> A sad recent error has been
> EU statements that everyone doing
> next gen internet research should be
> trying to converge on IPv6, but
> that's a whole other rant...
>
>
>
That's a rant I'm interested about. Where in your opinion does IPv6,
specially features such as flow label support, fit in the end to end
argument?
From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 06:25:38 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sun, 25 Oct 2009 13:25:38 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE44BDC.2050704@tcd.ie>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE44BDC.2050704@tcd.ie>
Message-ID:
ok, as you asked.
but this is euro-centric so others on the list might
not want to read on...
the next gen research programmes should be
about ideas that will postdate the internet -
IPv6 is, errm, around ~15 year old idea -
A few things came along in the last 15, 10, 5 years
that are already stressing out the basics -
of the entire type of networking that the subject line
discussion is about...
Lots of people can make their lists,
but in no particular order, my
problem with the entire approach to
nets predicated on packets and links and nodes
comes out of the pressure from
1. trying to do multihop, multiantennae radios
2. dealing with net coding
3. dealing with a future pretty soon now
where there are 10 billion mobile
devices and because of critical infrastructure,
we want to be organisationally (and not just topo/geo)
multihomed, and multipath (for resiliance of
access and flow resilience)
4. Coping with sub-lambda multiplexing
on 100Gbps optical paths... is another
strange vector (I suppose gMPLS afficionados
believe they have this one under control, but
I don't)
This had already start to creep in with
the internet of things, (sorry, I know thats just buzzword)
social nets, and content centric networking...
But new paradigms for traffic patterns
loosely starting with
content based networking,
now with very large scale rendezvous of
user contributed media and user interest...
The tension between authentic source identification,
(and sink), provenance of content,
and the requirements for privacy,
also puts a lot of pressure on the
net and application architecture
particularly when the matchmaking indixes
for this stuff have to be rebuilt faster and faster (see
what fb, imdb, amazon, etc etc)
have to do every night:)
(so they can get their targetted advertisement revenue
that lets us all use this stuff so cheap)
So where is the action?
That would be telling:-)
Flow labs and end-to-end arguments?
well, I guess what I am trying to say above
is that we are rapdily seeing the sublimation
of the entire naive idea of an "end point"
in network, transport and application terms
so I can't answer your specific query...
cheers
In missive <4AE44BDC.2050704 at tcd.ie>, Jaime Mateos typed:
>>Jon Crowcroft wrote:
>>> A sad recent error has been
>>> EU statements that everyone doing
>>> next gen internet research should be
>>> trying to converge on IPv6, but
>>> that's a whole other rant...
>>>
>>>
>>>
>>
>>That's a rant I'm interested about. Where in your opinion does IPv6,
>>specially features such as flow label support, fit in the end to end
>>argument?
cheers
jon
From mateosj at tcd.ie Sun Oct 25 07:15:54 2009
From: mateosj at tcd.ie (Jaime Mateos)
Date: Sun, 25 Oct 2009 14:15:54 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE44BDC.2050704@tcd.ie>
Message-ID: <4AE45D9A.7030808@tcd.ie>
Jon Crowcroft wrote:
> Flow labs and end-to-end arguments?
> well, I guess what I am trying to say above
> is that we are rapdily seeing the sublimation
> of the entire naive idea of an "end point"
> in network, transport and application terms
> so I can't answer your specific query...
>
>
Do you mean we need to redefine the "end points" beyond the conventional
meaning of hosts, but keep applying the end to end argument with its
bias towards simpler, more flexible networks; or that we should do away
with end to end, and recognize that the new demands/pressures you list
above can only be met with network based protocols?
Cheers,
Jaime
From jnc at mercury.lcs.mit.edu Sun Oct 25 08:03:03 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 25 Oct 2009 11:03:03 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025150303.B2AB16BE563@mercury.lcs.mit.edu>
[Apologies to all for dipping backwards a ways into the stream, but this
message contained what I felt was an important point to take on, and I didn't
have time/energy to do so last night.]
> From: Richard Bennett
>>> Moors shows that the Saltzer, Reed, and Clark argument for end-to-end
>>> placement is both circular and inconsistent with the FTP example that
>>> is supposed to demonstrate it.
>> I didn't see that at all.
> Moors points out that TCP error detection and recovery is an end-system
> function, but not really an endpoint function in the file transfer
> example.
This is all true, but I still don't see (for reasons such as that the
real-world FTP isn't the 'reliable FTP' the paper talks about) that it amounts
to "[the] argument for end-to-end placement is both circular and inconsistent
with the .. example that is supposed to demonstrate it", which is what I
disagreed with.
But this is not important, I would prefer to move on to a more important point.
>>> One of the more interesting unresolved questions about "End-to-End
>>> Args" is why it was written in the first place. Some people see it as
>>> a salvo in the ISO protocol wars, others as an attack in BBN's
>>> ARPANET, some as an attempt to criss the divide between engineering
>>> and policy
>> I don't know whether to be amused or outraged by this nonsense.
> I don't know why this question should get anybody upset, it's just a
> question about the context and motivation of the paper in the first
> place.
The problem is that it's like asking why Einstein wrote his thermionic
emissions paper. Even in a purely 'history of science' way, this question is
orders of magnitude less important than the question of the correctness of
the technical content itself.
And hoping that knowing exactly (even if one could know such a thing) _why_
it was written will tell you _anything_ about how correct it is, in and of
itself, is utterly misguided. Down that path lies "Transgressing the
Boundaries: Toward a Transformative Hermeneutics of Quantum Gravity".
To even bring the question of 'why was it written' up in a discussion about
the correctness of the technical content is, in a sense, to attack the very
ideals of technical debate, which is _supposed_ to focus on the technical
content, and leave all else (including people, and motivations), out of it.
> None of the authors was part of the inner circle of the Internet
> protocol design at the time the paper was written, although Clark was
> either the Chief Architect of the Internet or on his way to becoming
> same.
Say what? Reed was still deeply involved in Internet work at that point (he'd
been one of the people making the case to split TCP up into IP and TCP), as
was Clark (who was writing prototype TCP code, and papers based on the
lessons he learned doing so). And the two of them were extremely close
professional colleagues of Saltzer, with offices basically next door to each
other on the 5th floor. And although Jerry didn't go to meetings or write
code, as a key member of that research group, he was definitely thinking
about the things the rest were working on - as can be seen by his other
papers from that time period.
> I would have expected Cerf and Kahn to write something explaining the
> architectural decisions they made in adapting the framework to their
> system
I don't know Vint well enough to say with any confidence, but to hazard a
guess, but that kind of deep design philosophy thing just doesn't seem like
the kind of thing he'd go for - I think his focus was at a different level.
> Why these three people and why this particular time?
Why them? Because they were very close professional colleagues who habitually
thought at that level (i.e. design philosophy). Why then? Because at that
point they'd been thinking about networking for a while, and had gotten to
the point where they could usefully apply the kind of systems architecture
analysis that group was known for.
> It's never been explained.
The fact that you could even bother to ask that question, or think that the
answer is of any interest other than in a 'history of science' way, is very
illuminating.
> there was a lot of friction between the Network Working Group and BBN
> over the control BBN had over the ARPANET protocols inside the IMP.
Sure, but that was long before the period when 'End-End Arguments' was being
turned out.
> The interesting problems of the day in protocol design were all behind
> the curtain to the people who used the ARPANET, and that's frustrating
> to engineers. ... by 1981, people were well into the second step, and
> the closed implementation of the lower three layers was a problem.
Huh? Even by 1978 the people active in the Internet project treated the
ARPANet as a black box which we didn't really have much interest in, and
didn't really concern ourselves with it.
Frankly, for most of us, we were up to our asses in alligators getting all
these various new technologies (LANs, etc) up and running, and didn't have a
lot of time to worry about anything else anyway. What little time we did have
for deep thinking went to things like how to better organize OS software to
deal with networking, etc, etc.
Noel
From jnc at mercury.lcs.mit.edu Sun Oct 25 08:24:34 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 25 Oct 2009 11:24:34 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025152434.F2C916BE565@mercury.lcs.mit.edu>
> From: John Day
> This is why I was so shocked when the IETF refused to name the node in
> 1992. ... That was when it became clear that the IETF had become more a
> craft guild than an engineering group and relied more stock in
> tradition.
Some of us still have the scars on our foreheads from that one... :-)
> There was a further simplification that we couldn't see at that point.
To get back to actual technical content, that would be...? (I'm sure it's
obvious, but it's not coming up for me...)
Noel
From jnc at mercury.lcs.mit.edu Sun Oct 25 08:44:14 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 25 Oct 2009 11:44:14 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
> From: Richard Bennett
> On the subject of BBN's standing in the early Internet community, I'll
> simply note that the term "Big Bad Neighbor" was a common usage that I
> did not coin myself, and Steve Crocker's comments in RFC 1 had a
> well-understood subtext.
I think you're confusing the "early Internet community" with the 'early
ARPANet community'.
The view of the various divisions at BBN (since at one point the Internet work
was being done in a different division of BBN from that responsible for the
ARPANet) by other workers in the early Internet community was a complex, and
hence lengthy, one - and also off-scope for this list (may I suggest the
'Internet-history' list if you really want to explore the topic).
It seems to me that the 'end-end design ideas' have gotten mixed up in what
is, at the bottom, a fight over how to divide up the economic pie of
communication networks.
This is not an unknown occurrence - scientific work on things like the size
of the Artic ice-sheet, and discovery of new fossil species, has equally
become wound up in disputes which are far larger.
I don't have any pithy response to that, and any longer comment would also be
off-topic, so I will simply make the observation and leave it there.
Noel
From dpsmiles at gmail.com Sun Oct 25 09:02:28 2009
From: dpsmiles at gmail.com (Durga Prasad Pandey)
Date: Sun, 25 Oct 2009 09:02:28 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE35B6E.1080801@bennett.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com>
Message-ID: <928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com>
On Sat, Oct 24, 2009 at 12:54 PM, Richard Bennett wrote:
> I don't know why this question should get anybody upset, it's just a
> question about the context and motivation of the paper in the first place.
> None of the authors was part of the inner circle of the Internet protocol
> design at the time the paper was written, although Clark was either the
> Chief Architect of the Internet or on his way to becoming same. I would have
> expected Cerf and Kahn to write something explaining the architectural
> decisions they made in adapting the ?framework to their system, but their
> failure to do so meant someone else had to do it. Why these three people and
> why this particular time? It's never been explained.
RB,
Is your next email going to be about(humor me..) how a secret
underground cult (now called NASA) funded a young clerk called
Einstein to produce theories of relativity so they could "stage" the
spage age and eventually perform a cultish ritual on the moon?
(Actually I could have sold this storyline to Dan Brown for gazillions
of dollars.)
You quite obviously love conspiracy theories + juicy gossip and were
probably looking for some in your first email on this thread. Now you
are going to ridiculous lengths to explain yourself. :)
> Why these three people and why this particular time? It's never been explained.
This is a flagship question of conspiracy theorists.
You ask:
>>One of the more interesting unresolved questions about "End-to-End Args" is why it was written in the first place. Some people see it as a salvo in the ISO protocol wars, others as an attack in BBN's >>ARPANET, some as an attempt to criss the divide between engineering and policy, and there are probably other theories as well.
Conspiracy theories you mean?
One could ask these questions of almost any paper ever published. The
subtle thing they do is gently cast aspersions on the authors'
motivations. That's not a good thing to be trying to do.
The one good thing that your questions did is provoke detailed
responses from different people, some of which were very informative
to me(having been conceived well after TCP/IP, I do not have the
unique historical experience a lot of people on this list do). I liked
Dave Anderson's summary of the e2e paper too.
Durga
From L.Wood at surrey.ac.uk Sun Oct 25 09:10:11 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Sun, 25 Oct 2009 16:10:11 -0000
Subject: [e2e] Protocols breaking the end-to-end argument
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
<4AE44183.80908@reed.com>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk>
> So let's not study wars and battles. Let's study architectural
> principles and their application.
So it is a principle after all, then?
(It strikes me that if one is aspiring to be Darwin one shouldn't
also have to be Dawkins.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/01a7f636/attachment.html
From dpsmiles at gmail.com Sun Oct 25 09:18:25 2009
From: dpsmiles at gmail.com (Durga Prasad Pandey)
Date: Sun, 25 Oct 2009 09:18:25 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE35B6E.1080801@bennett.com>
<928807280910250902s473e3e4bq95b7a8895471a615@mail.gmail.com>
Message-ID: <928807280910250918p1eaeafffx9dad624f6186efde@mail.gmail.com>
Actually, after having read Noel's latest email, I realize my email
was redundant(he articulated all I meant to say, and more, much more,
umm, articulately..). Though I love the coincidence in reference to
Einstein. (btw, coincidences are fertile grounds for conspiracy
theories!).
On Sun, Oct 25, 2009 at 9:02 AM, Durga Prasad Pandey wrote:
> On Sat, Oct 24, 2009 at 12:54 PM, Richard Bennett wrote:
>
>> I don't know why this question should get anybody upset, it's just a
>> question about the context and motivation of the paper in the first place.
>> None of the authors was part of the inner circle of the Internet protocol
>> design at the time the paper was written, although Clark was either the
>> Chief Architect of the Internet or on his way to becoming same. I would have
>> expected Cerf and Kahn to write something explaining the architectural
>> decisions they made in adapting the ?framework to their system, but their
>> failure to do so meant someone else had to do it. Why these three people and
>> why this particular time? It's never been explained.
>
> RB,
>
> Is your next email going to be about(humor me..) how a secret
> underground cult (now called NASA) funded a young clerk called
> Einstein to produce theories of relativity so they could "stage" the
> spage age and eventually perform a cultish ritual on the moon?
> (Actually I could have sold this storyline to Dan Brown for gazillions
> of dollars.)
>
> You quite obviously love conspiracy theories + juicy gossip and were
> probably looking for some in your first email on this thread. Now you
> are going to ridiculous lengths to explain yourself. ?:)
>
>> Why these three people and why this particular time? It's never been explained.
>
> This is a flagship question of conspiracy theorists.
>
> You ask:
>
>>>One of the more interesting unresolved questions about "End-to-End Args" is why it was written in the first place. Some people see it as a salvo in the ISO protocol wars, others as an attack in BBN's >>ARPANET, some as an attempt to criss the divide between engineering and policy, and there are probably other theories as well.
>
> Conspiracy theories you mean?
>
> One could ask these questions of almost any paper ever published. The
> subtle thing they do is gently cast aspersions on the authors'
> motivations. That's not a good thing to be trying to do.
>
> The one good thing that your questions did is provoke detailed
> responses from different people, some of which were very informative
> to me(having been conceived well after TCP/IP, I do not have the
> unique historical experience a lot of people on this list do). I liked
> Dave Anderson's summary of the e2e paper too.
>
> Durga
>
--
?Never doubt that a small group of thoughtful, committed citizens can
change the world. Indeed, it's the only thing that ever has.?
-- Margaret Mead
From Jon.Crowcroft at cl.cam.ac.uk Sun Oct 25 09:39:34 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Sun, 25 Oct 2009 16:39:34 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE45D9A.7030808@tcd.ie>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
<4AE44BDC.2050704@tcd.ie>
<4AE45D9A.7030808@tcd.ie>
Message-ID:
Jaime,
maybe - i'm too staid and stuck in my ways to come up with
new stuff, but it worries me
i) that we use simple graphs and
labeling to describe things (wireless) that isnt
ii) there are ways to do content centric networking
(couple of papers comin up in CoNeXT this year in Rome)
mapped into ipv6 which only slightly fly in the face of the
ipv6 address structuring conventiosn (there are always ways
to hash object id's into a bit number space) but that doesn't
address some of the things one might do with time shifting
iii) I'm aware that there are people workin on "fuzzy end
points" - perhaps this is just the mist around the edge of
clouds...
iv) i'm not sure people take on board what new technology
like multicore do to your OS/protocol stack
or like Terminator does to your code safety/security
enough...
and lots more stuff
In missive <4AE45D9A.7030808 at tcd.ie>, Jaime Mateos typed:
>>Jon Crowcroft wrote:
>>> Flow labs and end-to-end arguments?
>>> well, I guess what I am trying to say above
>>> is that we are rapdily seeing the sublimation
>>> of the entire naive idea of an "end point"
>>> in network, transport and application terms
>>> so I can't answer your specific query...
>>Do you mean we need to redefine the "end points" beyond the conventional
>>meaning of hosts, but keep applying the end to end argument with its
>>bias towards simpler, more flexible networks; or that we should do away
>>with end to end, and recognize that the new demands/pressures you list
>>above can only be met with network based protocols?
cheers
jon
From dpreed at reed.com Sun Oct 25 10:13:48 2009
From: dpreed at reed.com (David P. Reed)
Date: Sun, 25 Oct 2009 13:13:48 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk>
References: <20091025035904.356D26BE5DF@mercury.lcs.mit.edu>
<4AE44183.80908@reed.com>
<4835AFD53A246A40A3B8DA85D658C4BE01368B23@EVS-EC1-NODE4.surrey.ac.uk>
Message-ID: <4AE4874C.9000202@reed.com>
On 10/25/2009 12:10 PM, L.Wood at surrey.ac.uk wrote:
>
> > So let's not study wars and battles. Let's study architectural
> > principles and their application.
>
> So it is a principle after all, then?
>
> (It strikes me that if one is aspiring to be Darwin one shouldn't
> also have to be Dawkins.)
>
To be precise, the end-to-end argument refers to a class of arguments,
with a few free variables. Jerry and I (and perhaps Dave) have long
been students of a thing called "rhetoric". In classical rhetoric (a
la Aristotle), one discusses what kinds of arguments are valid. Logic
is a part of rhetoric, but rhetoric as a whole includes many other
aspects of argumentation.
Linking rhetoric to formal logic, the end-to-end argument would be one
of a set of "rules of inference" - acceptable combinators that take
other factors into account and provide new valid statements.
Substituting for the free variables in the end-to-end argument provides
a large set of implied valid statements.
Now rhetoric includes the mechanisms for argumentation where there is
not one "truth". In fact, in general, rhetoric handles cases where one
line of argumentation supports a particular decision, and another line
supports a different decision. Therefore, rhetoric has been part of the
general set of tools that lawyers use for argumentation - there is no
guarantee that all laws are consistent, nor are their set of valid
arguments complete in the sense of deciding every case.
Architecture is like that: it is why good systems architects need to
understand rhetoric in all of its glory.
Examples of rhetoric:
The much misunderstood "ad hominem argument" - which is an argument that
makes claims based on who is making a particular claim. The term has
been redefined in popular culture to mean "insult", but in fact it was
never that.
The argument "post hoc ergo propter hoc". That is the idea that
"correlation equals causation" - John Day's argument that because of the
date of publication, Jerry Dave and I must have invented the argument as
part of some contemporaneous battle about network adoption.
etc.
I commend study of rhetoric to all. It helps decode the rather strange
logics that pervade discourse today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091025/a77f1aec/attachment.html
From perfgeek at mac.com Sun Oct 25 11:31:07 2009
From: perfgeek at mac.com (rick jones)
Date: Sun, 25 Oct 2009 11:31:07 -0700
Subject: [e2e] TCP offload (was part of Protocols breaking the
end-to-end argument)
In-Reply-To: <4AE31066.8010109@reed.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
<4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com>
Message-ID: <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com>
On Oct 24, 2009, at 7:34 AM, David P. Reed wrote:
> Because I sense this thread might be interesting, and should be
> separated from the trolling going on in the original thread, I
> changed the title.
>
> TCP offload is interesting. We actually addressed this kind of
> thing is the "Active Networks" vs. end-to-end paper. Function
> placement at the architectural level actually can be discussed with
> regard to "design time" and "implementation time" versions of the
> arguments. For example, if I am an "end host" but I do some of my
> functions on "attached support processors" (excuse the "I" as
> metaphor for the main OS and CPU), that may be quite clean
> architecturally - IF the communication between me and the attached
> support processor is one that makes it act as part of "me". So one
> could consider it part of the "end", even if it is in a middlebox:
> the distinction is that it is under my sole control (so it acts as a
> fully controlled module).
>
> The end-to-end argument in the paper says that such acceleration can
> be in the network, if indeed it merely accelerates a function that
> is in all endpoints. However, the argument asks that we consider
> whether the improvement overall is really worth it.
>
> I leave it to the community of architects (not the chip designers,
> who have a bias to believe that every "feature" is a differentiating
> advantage) to decide whether the benefit of this particular thing is
> really worth the potential inflexibility it creates - in particular
> the risk that the chip will do the wrong thing on the forwarding
> path, and the risk that the TCP spec will change in a way that makes
> the chip's popularity a barrier to innovation.
>
> It sounds as if there is a chance that, due to how one of the TOS
> chips works, the portion of TCP that it implements is not strictly
> an "agent" of the host TCP stack running on the host processor, but
> instead based on "pattern recognition" that cannot be turned off.
> (I haven't read the spec, so maybe it is more subtle than that).
I don't interact much with "big TOE" functionality (full stateful
protocol offload - TCP Offload Engine) but the "little toe" stateless
stuff - ChecKsum Offload (CKO), TSO, LRO. I have yet to encounter a
card/chip/NIC where those little toes cannot be cut-off (to spite what
I'm not sure :) LRO (distict from GRO perhaps) may be one where it is
either on or off. CKO and TSO are ones where they can be on, off, or
on and ignored by the stack.
rick jones
Wisdom teeth are impacted, people are affected by the effects of events
From craig at aland.bbn.com Sun Oct 25 12:51:17 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Sun, 25 Oct 2009 15:51:17 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091025195117.B871528E137@aland.bbn.com>
> It wasn't until CLNP that I ever perceived a 'war' (or competition). To
> me, it was always apparent that the war wasn't with the protocols per
> se, but rather the corporate entities that wanted to control pricing.
I find this historical discussion interesting because it suggests some
very different vantage points.
My vantage point was close to John Day's. I was at BBN (arrived in 1983)
and there were internal debates of TCP/IP vs. TP0/X.25 with the additional
twist that folks like John and Ross Callon were working to develop TP4/CLNP
to compete with TP0/X.25.
We had cheerful debates over CLNP vs. IP. (I read a draft or two of the
CLNP specs for Ross -- which led to an odd statement later during the
protocol wars where I was asked if I'd read the CLNP spec and the answer,
honestly, was "no" -- I'd read the earlier drafts... and I got pilloried for
commenting on CLNP without reading it that bit of stupidity on my part).
But the big fight was TCP/IP vs. TP0/X.25 (or, more truthfully, my recollection
was the fight was TCP vs. X.25 -- where to put the smarts...)
Thanks!
Craig
From richard at bennett.com Sun Oct 25 19:04:49 2009
From: richard at bennett.com (Richard Bennett)
Date: Sun, 25 Oct 2009 19:04:49 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
Message-ID: <4AE503C1.8040903@bennett.com>
Noel Chiappa wrote:
> It seems to me that the 'end-end design ideas' have gotten mixed up in what
> is, at the bottom, a fight over how to divide up the economic pie of
> communication networks.
You mean the end-to-end design ideas have gotten mixed up in a fight
over not changing how the economic pie is currently divided. 37 years of
networking history boils down to this:
1. Pouzin designs CYCLADES as a layered system of protocols in order to
experiment with some interesting ideas about reliability, performance,
and routing; it's all based on datagrams.
2. Pouzin and Kahn share some ideas and Internet ends up following the
same design as CYCLADES, modulo addressing. DECNet, XNS, and TP4/CLNP
follow.
3. End-to-End Args proposes applying the notion of smart, reliable
endpoints communicating over unreliable comms system to all sorts of
other things as a rhetorical trick.
4. Internet eventually becomes an open (public) system.
5. RFC 1958 says "let's not descend into dogma."
6. Clark and Blumenthal's Brave New World says "end to end still has value."
7. Lessig reads Brave New World as saying "capitalism is corrupting the
Internet; Save End-to-End!"
8. Moors points out that E2E Args never did describe the Internet.
9. AT&T admits to being a capitalist entity.
10. Google's MCI vets worry that telcos will put them out of business
like they did MCI unless end-to-end is law.
11. Public interest groups push for end-to-end law.
12. FCC asks: "What's wrong with descending into dogma? That's what we do."
13. Angry old hippies go "Right on, FCC, your daddy's Internet is good
enough for you!"
And that's where we are today.
RB
From L.Wood at surrey.ac.uk Sun Oct 25 23:19:29 2009
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Mon, 26 Oct 2009 06:19:29 -0000
Subject: [e2e] Protocols breaking the end-to-end argument
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
<4AE503C1.8040903@bennett.com>
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk>
> 3. End-to-End Args proposes applying the notion of smart, reliable
> endpoints communicating over unreliable comms system to all sorts of
> other things as a rhetorical trick.
Reed's comment on rhetoric bringing structure to logical argument
has nothing to do with a paper doing engineering analysis and
drawing insights from commonalities.
(I would submit that to fully understand its arguments and internalize
its concepts, an engineering mindset is required.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/e9c54fc2/attachment.html
From richard at bennett.com Mon Oct 26 02:07:20 2009
From: richard at bennett.com (Richard Bennett)
Date: Mon, 26 Oct 2009 02:07:20 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk>
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
<4AE503C1.8040903@bennett.com>
<4835AFD53A246A40A3B8DA85D658C4BE01368B24@EVS-EC1-NODE4.surrey.ac.uk>
Message-ID: <4AE566C8.7070203@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/e7f98ec6/attachment.html
From william.allen.simpson at gmail.com Mon Oct 26 05:53:18 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Mon, 26 Oct 2009 08:53:18 -0400
Subject: [e2e] TCP offload (was part of Protocols breaking the
end-to-end argument)
In-Reply-To: <1D769A86-46B5-49C6-9E64-915F892200C8@mac.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
<4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com>
<1D769A86-46B5-49C6-9E64-915F892200C8@mac.com>
Message-ID: <4AE59BBE.8070000@gmail.com>
rick jones wrote:
>
> On Oct 24, 2009, at 7:34 AM, David P. Reed wrote:
>
>> I leave it to the community of architects (not the chip designers, who
>> have a bias to believe that every "feature" is a differentiating
>> advantage) to decide whether the benefit of this particular thing is
>> really worth the potential inflexibility it creates - in particular
>> the risk that the chip will do the wrong thing on the forwarding path,
>> and the risk that the TCP spec will change in a way that makes the
>> chip's popularity a barrier to innovation.
>>
> I don't interact much with "big TOE" functionality (full stateful
> protocol offload - TCP Offload Engine) but the "little toe" stateless
> stuff - ChecKsum Offload (CKO), TSO, LRO. I have yet to encounter a
> card/chip/NIC where those little toes cannot be cut-off (to spite what
> I'm not sure :) LRO (distict from GRO perhaps) may be one where it is
> either on or off. CKO and TSO are ones where they can be on, off, or on
> and ignored by the stack.
>
TCP Checksum Offload (shouldn't that be TCO or CSO?) has been done for
years. I've always been a bit leery of it, as my many experiences with
bus problems indicates that the checksum should be calculated as close to
the CPU as possible....
TCP Segment Offload (TSO) -- large TCP segments are broken into smaller
ones -- wouldn't be a problem where the stack always feeds the chip
properly-sized PMTU segments. For routing a LAN jumbogram into a WAN,
that's broken! The drivers had better be smart enough to honor "Don't
Fragment" (DF), even though that technically only applies to IP. Best to
turn it off for all routed packets. Does your implementation?
TCP Large Receive Offload (LRO) -- small TCP segments are combined into
larger ones -- is an unmitigated disaster. The sender has no ability to
turn it off, and no idea that it's happening. Assuming it leaves
SYN-bearing segments untouched, I'd still think that breaks almost every
existing Ack-bearing TCP option.
In either of the latter cases, I don't see how PAWS Timestamps or the MD5
Authentication Option would ever work.
From william.allen.simpson at gmail.com Mon Oct 26 06:54:09 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Mon, 26 Oct 2009 09:54:09 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091025195117.B871528E137@aland.bbn.com>
References: <20091025195117.B871528E137@aland.bbn.com>
Message-ID: <4AE5AA01.6070800@gmail.com>
Craig Partridge wrote:
>> It wasn't until CLNP that I ever perceived a 'war' (or competition). To
>> me, it was always apparent that the war wasn't with the protocols per
>> se, but rather the corporate entities that wanted to control pricing.
>
> I find this historical discussion interesting because it suggests some
> very different vantage points.
>
Yes. Mine was much closer to the view of Noel Chiappa, where he says:
# Frankly, for most of us, we were up to our asses in alligators getting all
# these various new technologies (LANs, etc) up and running, and didn't have a
# lot of time to worry about anything else anyway. What little time we did have
# for deep thinking went to things like how to better organize OS software to
# deal with networking, etc, etc.
#
But I'd also the experience of actually trying to order links. It was
quite difficult. Then, AT&T required putting these little gray boxes on
every data line, and charging double (or more) the usual voice rate. We
took the box apart, and discovered that we could build the same thing for
less than 35 cents retail, but they were charging hundreds of dollars per
year (forever).
So, for me, the Green decision couldn't have come soon enough. And we
did everything under the sun to avoid AT&T links. Maybe that's the
underlying reason that X.25 wasn't a competitor, as we were using it as
little as possible.
> My vantage point was close to John Day's. I was at BBN (arrived in 1983)
> and there were internal debates of TCP/IP vs. TP0/X.25 with the additional
> twist that folks like John and Ross Callon were working to develop TP4/CLNP
> to compete with TP0/X.25.
>
By 1981, I'd left the University for a small startup that did front-end data
concentrators (using the HP 21MX with nicely re-programmable microcode for
handling data). Over a couple of years, we did a couple of dozen protocols,
none of which were X.25.
By 1983, I'd become a full-time consultant. Auto companies and suppliers,
political campaigns -- none of them ever expressed any interest in X.25.
Lots of serial multi-point cabling connected to front-ends talking to
back-ends over various proprietary data channels or (thick) ethernet in
electronically noisy, chaotic environments.
> But the big fight was TCP/IP vs. TP0/X.25 (or, more truthfully, my recollection
> was the fight was TCP vs. X.25 -- where to put the smarts...)
>
Believe me, there is nothing that can better reinforce the absolute
necessity for end-to-end transmission control than heterogeneous networking
on a factory floor over multiple hops, or with a satellite link in the
middle. Nothing else actually works! More important, nothing else is
testable by a factory electrician or (usually mechanical) engineer that
has to debug and fix the link. The smarts has to be located in the CPE.
If folks at BBN were still talking about X.25, they were way behind the
curve, or were badly infected with severe standard-committee-itis.
From craig at aland.bbn.com Mon Oct 26 07:10:33 2009
From: craig at aland.bbn.com (Craig Partridge)
Date: Mon, 26 Oct 2009 10:10:33 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091026141033.2C07D28E137@aland.bbn.com>
> If folks at BBN were still talking about X.25, they were way behind the
> curve, or were badly infected with severe standard-committee-itis.
The latter.
Recall that part of BBN's networking team was paid by NIST to represent
the US at ISO/CCITT meetings. So BBN was simultaneously pushing ahead
on TCP/IP work AND working with ISO/CCITT on ISO standards.
Add to this that it was official US policy at the time that they'd
transition from TCP/IP to the OSI standards, and so there was much
effort inside BBN to try to get the OSI standards to a good enough
state to be transitioned to, and there was pushback from other
countries represented at ISO, and you have the internal debates.
Thanks!
Craig
From dpreed at reed.com Mon Oct 26 07:23:35 2009
From: dpreed at reed.com (David P. Reed)
Date: Mon, 26 Oct 2009 10:23:35 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE503C1.8040903@bennett.com>
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
<4AE503C1.8040903@bennett.com>
Message-ID: <4AE5B0E7.8090107@reed.com>
On 10/25/2009 10:04 PM, Richard Bennett wrote:
> 37 years of networking history boils down to this:
...
> 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good
> enough for you!"
>
What a warped interpretation of history... it discredits itself, in my
opinion only, of course. If this were a forum for discussing policy
matters, I'd engage in debunking it. It is not such a forum, however.
This is a research forum, loosely associated with the IRTF, and
Bennett's comments (true or not) have not contributed to this forum.
With regard to historical analysis, Bennett (and his informants) are
welcome to write an article for ACMs Annals in the History of Computing,
where actual historians apply peer review to such claims and submissions.
The use of the phrase "rhetorical trick" is offensive to me personally.
Bennett persists in this claim, and John Day surprisingly (to me) joins
him in this warped idea that our paper was written as a move in a battle
(war) that some would claim was relevant to today. That it offends me
personally doesn't matter that much in the scheme of things - certainly
Bennett's strange historical analysis of "causation" wouldn't stand a
test against facts.
However, it is clear we must take Bennett seriously: Jon Peha (FCC Chief
Technologist), Robert Pepper (former FCC senior exec and Cisco senior
exec), Rob Atkinson (progressive political activist and friend of Blair
Levin), and several Congress members (including Darryl Issa) support the
organization that employs Bennett as a Senior Fellow where he makes this
set of claims (ITIF) *as part of his job*. That organization claims to
be a "non-partisan think tank" devoted to research and analysis. So I'd
suggest that this analysis be subjected to rigorous review - but NOT on
an IRTF list. Perhaps Bennett's claim (made in his online resume) that
he was "responsible" for major networking standards, "including ... WiFi
and UWB" will also be reviewed rigorously, again, not on this list, but
elsewhere, perhaps by the FCC. Many people on this list know some of
the people who are given credit for 802.11 in the community -- you're
welcome to ask them about Bennett.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/fc7f7cf2/attachment-0001.html
From dhc2 at dcrocker.net Mon Oct 26 07:52:33 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Mon, 26 Oct 2009 07:52:33 -0700
Subject: [e2e] Tussle-points
In-Reply-To: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
References: <20091024180015.91FF16BE55B@mercury.lcs.mit.edu>
Message-ID: <4AE5B7B1.4050905@dcrocker.net>
Noel Chiappa wrote:
> For one, NATs became widespread mostly a result of flaws in the original
> engineering (too small an address space) and architecture (too few namespaces,
> leading to difficulty in supporting things like provider independence). NATs
> are not inherently desirable, and would not, I think, have
> evolved/proliferated had TCP/IP avoided those (in hindsight, now obvious)
> mistakes.
The name "NAT" certainly justifies the claim that they were created to resolve
an issue with addressing. And given what they do to an address, they certainly
affect end-to-end behaviors.
But there is pretty strong indication that something like them would have been
needed anyhow. For example... Back when CIDR was being deployed -- and repeated
in the Tussles in Cyberspace paper -- it was observed that the way addresses are
structured locks a user into their provider. NATs fix that (if you don't have
any publicly-visible servers inside your net.) In other words, NATs have
important administrative benefits that need to be acknowledged.
The interface between an organization and the outside world needs a potentially
sophisticated boundary device, no matter how wonderful the Net's addressing
scheme.
Whether the legitimate services of such a boundary device impinges on E2E
principles is a worthy discussion, but we ought to be careful not to dismiss the
topic with the usual, quick wave of the E2E flag over the limited and rotten
corpse of the address-translation-is-bad assertion.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
From perfgeek at mac.com Mon Oct 26 08:12:58 2009
From: perfgeek at mac.com (rick jones)
Date: Mon, 26 Oct 2009 08:12:58 -0700
Subject: [e2e] TCP offload (was part of Protocols breaking the
end-to-end argument)
In-Reply-To: <4AE59BBE.8070000@gmail.com>
References: <4AE184EE.5040800@tcd.ie> <4AE1A414.4090302@gmail.com>
<4AE1CDE1.5070205@reed.com>
<070399CF-B67C-41E0-95A3-A528A931A1E6@mac.com>
<4AE2EDB0.3010406@gmail.com> <4AE31066.8010109@reed.com>
<1D769A86-46B5-49C6-9E64-915F892200C8@mac.com>
<4AE59BBE.8070000@gmail.com>
Message-ID:
On Oct 26, 2009, at 5:53 AM, William Allen Simpson wrote:
> TCP Checksum Offload (shouldn't that be TCO or CSO?)
It wouldn't be the former for it is used for UDP as well. As for CSO
vs CKO, a (stinking?) rose by any other name I suppose. The feature
got named CKO, I'm content to leave it as such.
> TCP Segment Offload (TSO) -- large TCP segments are broken into
> smaller
> ones -- wouldn't be a problem where the stack always feeds the chip
> properly-sized PMTU segments.
I may have misunderstood your wording, but if TCP has already
segmented, there wouldn't be much if any offloading. The stack hands
the chip everything it needs to know to make properly-sized segments
on each large send. (IIRC Solaris experimented with Multi Data
Transmit (MDT - a joy of a search term...) where they did have TCP do
all the segmentation and all it did was pass a list of multiple
segments in one go (not unlike packet trains in say HP-UX 8.07 IP
fragmentation and elsestacks I suspect) but that "poor man's TSO" I
don't think went very far even though it could give a little boost
over a non-TSO-capable NIC. "All" the NICs can do TSO now. (TSO
itself is sometimes referred to as "poor man's Jumbo Frames" and we
would circle-back to a de jure MTU that has remained unchanged for
decades....)
> For routing a LAN jumbogram into a WAN,
> that's broken! The drivers had better be smart enough to honor "Don't
> Fragment" (DF), even though that technically only applies to IP.
> Best to
> turn it off for all routed packets. Does your implementation?
I do not have my own TCP/IP stack :) I interact to varying degrees
with the stacks of others. Based on that experience, the decision to
do TSO is on a send by send basis. TCP sets-up the send to be either
TSO or non-TSO, the driver does the appropriate thing to the packet
descriptor(s) to inform the NIC. While I cannot say that I've gone
looking for the code in Linux and elsewhere, unless IP tries to set it
up on a routed datagram, and I do not believe it does, TSO will not be
applied as the datagram leaves via the egress interface.
> TCP Large Receive Offload (LRO) -- small TCP segments are combined
> into
> larger ones -- is an unmitigated disaster. The sender has no
> ability to
> turn it off, and no idea that it's happening. Assuming it leaves
> SYN-bearing segments untouched, I'd still think that breaks almost
> every
> existing Ack-bearing TCP option.
You must really like the HP-UX and Solaris (and any other Mentat-
derived stack's) ACK avoidance heuristics :) Another example of
customer LAN/MAN needs/desires coming-up against what is felt to be
necessary for the big-I Internet. IIRC the Solaris stack does attempt
to make a distinction between local and remote when deciding to (not)
apply the ACK avoidance heuristic. Both have mechanisms to evolve up
to their levels of avoidance and devolve back to the chapter-and-verse
ack-every-other behaviour suggested by the RFCs in the presence of
anomalies. Both can be controlled completely (on, off, degree) by the
system administrator.
> In either of the latter cases, I don't see how PAWS Timestamps or
> the MD5
> Authentication Option would ever work.
PAWS Timestamps need-not (should not?) be unique from segment to
segment, only from window to window or transmission to retransmission
yes? So, on the sending side, since the host TCP is very much in
control, if a sequence of N segments would have a PAWS increment in
the middle, TCP can split the large send into two at that point.
I do not know if GRO (or the card-based LRO) does the opposite on the
way in, but I could easily see (and not actually) them checking and
asking "is this timestamp the same as the previous" when making
coalescing decisions.
rick jones
Wisdom teeth are impacted, people are affected by the effects of events
From richard at bennett.com Mon Oct 26 10:20:13 2009
From: richard at bennett.com (Richard Bennett)
Date: Mon, 26 Oct 2009 10:20:13 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE5B0E7.8090107@reed.com>
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
<4AE503C1.8040903@bennett.com> <4AE5B0E7.8090107@reed.com>
Message-ID: <4AE5DA4D.1040806@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/424938fc/attachment.html
From dpreed at reed.com Mon Oct 26 10:44:43 2009
From: dpreed at reed.com (David P. Reed)
Date: Mon, 26 Oct 2009 13:44:43 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE5DA4D.1040806@bennett.com>
References: <20091025154414.D29126BE56B@mercury.lcs.mit.edu>
<4AE503C1.8040903@bennett.com> <4AE5B0E7.8090107@reed.com>
<4AE5DA4D.1040806@bennett.com>
Message-ID: <4AE5E00B.2090909@reed.com>
Note: I did not and have never tried to get Bennett fired. I will say
that it is my opinion (openly held) that ITIF gains little from
employing him as a spokesperson, and that Bennett has several times
expressed the idea that my employment at MIT is somehow not to his liking.
On 10/26/2009 01:20 PM, Richard Bennett wrote:
> Excellent response, David Reed. Don't forget that the FCC's Notice of
> Proposed Rulemaking on Internet regulation quotes me re: the fact that
> Pouzin invented the framework that we find in the Internet protocols
> and four other systems of that era.
>
> BTW, I'm not participating on this e-mail list as part of my job, but
> I'm sure David Reed will go ahead and try to get me fired again for
> having the nerve to question his reasoning; it's been about a week
> since he did that, so it's probably time again.
>
> Meanwhile, I'm revising my "Designed for Change" paper for
> publication. The discussion about rhetoric and all has been very
> illuminating regarding the motivation for the paper what has been
> claimed to fuel the debate on Internet regulation, but to me the paper
> seems to be a more a creature of some of the fashions of its age (RISC
> and all that sort of thing.) Some applications have worked out well,
> others not; do we know why?
>
> RB
>
> David P. Reed wrote:
>> On 10/25/2009 10:04 PM, Richard Bennett wrote:
>>> 37 years of networking history boils down to this:
>> ...
>>> 13. Angry old hippies go "Right on, FCC, your daddy's Internet is
>>> good enough for you!"
>>>
>>
>>
>> What a warped interpretation of history... it discredits itself, in
>> my opinion only, of course. If this were a forum for discussing
>> policy matters, I'd engage in debunking it. It is not such a forum,
>> however. This is a research forum, loosely associated with the IRTF,
>> and Bennett's comments (true or not) have not contributed to this forum.
>>
>> With regard to historical analysis, Bennett (and his informants) are
>> welcome to write an article for ACMs Annals in the History of
>> Computing, where actual historians apply peer review to such claims
>> and submissions.
>>
>> The use of the phrase "rhetorical trick" is offensive to me
>> personally. Bennett persists in this claim, and John Day
>> surprisingly (to me) joins him in this warped idea that our paper was
>> written as a move in a battle (war) that some would claim was
>> relevant to today. That it offends me personally doesn't matter that
>> much in the scheme of things - certainly Bennett's strange historical
>> analysis of "causation" wouldn't stand a test against facts.
>>
>> However, it is clear we must take Bennett seriously: Jon Peha (FCC
>> Chief Technologist), Robert Pepper (former FCC senior exec and Cisco
>> senior exec), Rob Atkinson (progressive political activist and friend
>> of Blair Levin), and several Congress members (including Darryl Issa)
>> support the organization that employs Bennett as a Senior Fellow
>> where he makes this set of claims (ITIF) *as part of his job*. That
>> organization claims to be a "non-partisan think tank" devoted to
>> research and analysis. So I'd suggest that this analysis be
>> subjected to rigorous review - but NOT on an IRTF list. Perhaps
>> Bennett's claim (made in his online resume) that he was "responsible"
>> for major networking standards, "including ... WiFi and UWB" will
>> also be reviewed rigorously, again, not on this list, but elsewhere,
>> perhaps by the FCC. Many people on this list know some of the people
>> who are given credit for 802.11 in the community -- you're welcome to
>> ask them about Bennett.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091026/107e3a4b/attachment.html
From jnc at mercury.lcs.mit.edu Mon Oct 26 18:13:10 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 26 Oct 2009 21:13:10 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091027011310.C49266BE612@mercury.lcs.mit.edu>
> From: Richard Bennett
>> It seems to me that the 'end-end design ideas' have gotten mixed up in
>> what is, at the bottom, a fight over how to divide up the economic pie
>> of communication networks.
> You mean the end-to-end design ideas have gotten mixed up in a fight
> over not changing how the economic pie is currently divided.
Err, 'the current division pattern' is one of the possible answers to the
question 'how should the economic pie of communication networks be divided
up', I would have thought. But this is not important, let me move on...
> End-to-End Args proposes applying the notion of smart, reliable
> endpoints communicating over unreliable comms system to all sorts of
> other things as a rhetorical trick.
'Distributed systems' is a long-standing area of interest in computing
'science' (but that's a different rathole), and it covers a far larger field
than simply communication networks (which is the subject area in which the
end-end analysis originated).
The design philosophy framework discussed in "End-to-End Arguments", while
originating in an analysis of communication networks, can viably be applied
to a wide variety of distributed systems (say, for instance, a distributed
file system which uses replication for robustness and performance). Calling
the application to such a system, in the larger problem domain, "a rhetorical
trick" seems considerably 'over the top' to me.
Moreover, your phraseology above ("End-to-End Args proposes applying the
notion ... to all sorts of other things as a rhetorical trick") seems to
imply that a principal feature of the paper are attempts to apply the
end-to-end argument to places outside the computerized information systems
domain. In fact, there is only paragraph, in the section entitled "History,
and application to other system areas" which deals with such examples. That
hardly qualifies as what your wording implies - which is that such
expansionary applications are a major thrust of the paper.
You're also incorrect to characterize even that paragraph as "applying the
notion of smart, reliable endpoints communicating over unreliable comms
system". The banking example certainly doesn't fit that rubric. It would be
more apt to describe the examples in that paragraph as examples of "functions
placed at low levels of a system [which] may be redundant or of little value
when compared with the cost of providing them at that low level" - that
phrase, of course, being from the paper's own abstract.
> Moors points out that E2E Args never did describe the Internet.
I think this is again a misreprentation of what the Moors paper says - but
we've been down that rabbit hole before.
> 10. Google's MCI vets worry that telcos will put them out of business
> like they did MCI unless end-to-end is law.
> 11. Public interest groups push for end-to-end law.
> 12. FCC asks: "What's wrong with descending into dogma? That's what we do."
Policy and engineering are two very different problem domains, and the former
is free to ignore the latter, if other external (i.e. non-engineering) factors
make that the preferable choice. (Within limits, of course; I treat that point
last.)
Just because an engineering discipline says 'X is the way to go', that
doesn't mean policy has to follow. As a made-up example, country Y might
decide that for non-engineering reasons, they prefer to ban gas turbines as
aircraft engines, in favour of piston engines (perhaps because they don't
like the high-pitched whine of turbines, say). However, clearly, if country Y
communally makes the decision to ban gas turbines, that's their call - even
at the same time that it remains a non-optimal decision from an _engineering_
perspective.
The interesting question, of course, is whether it's good public policy to
make policy choices that are a non-optimal decision from an engineering
perspective. Clearly in cases where that is done there will be a price to pay
(e.g. in the example above, slower planes, and higher fuel consumption), but
only the community in question can decide if those costs are worth the
benefits (e.g. getting rid of turbine whine). There is no general principle
one can apply in such cases, to decide whether or not to follow the optimal
engineering path; each will have to be decided on the overall merits.
So if some factions are calling for an 'end-to-end law' (whatever that might
be - my opinion would be that that is a poor name, although I can see where
it came from), that's a legitimate policy position, on a legitimate policy
decision. Engineering can only provide data to that debate, as to whether
it's the most efficient choice, or not - as in the gas turbine example.
The one place policy _cannot_ go is to _ignore hard constraints_. As Feynman
so elegantly put it (in his appendix to the 'Challenger' crash report'):
"For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled."
> 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good
> enough for you!"
The implication here seems to be that people who advocate a certain position
on how to divide up the network pie are also associated with a certain place
on the political spectrum - at least, in terms of their views on economics?
(Those who know me will no doubt be as amused as I am by the seeming
supposition that I might fall into this imaginary category - but I digress.)
I haven't actually stated here anything about my views on how to divide up the
network money pie. Actually, I don't really care about that issue: although I
do have views on what kind of service model the network should offer, they are
driven by other factors, such as engineering.
All of which should serve to make several points that everyone should retain -
that discussing whether or not the End-to-End princple is a good/valid
engineering point is separate from the question of what service model the
network should offer to its customers - and that people can have positions on
that latter question which are utterly not a result of their views (if any) on
the issue of how to divide up the network pie.
Some consequences in the latter will obviously be a _result_ of their position
on the service model, of course, but it should be noted that the effects on
the pie division are a _result_ of their position on the service model issue,
not the _cause_ of the latter - seemingly unlike that for some other people.
Noel
From richard at bennett.com Mon Oct 26 20:33:51 2009
From: richard at bennett.com (Richard Bennett)
Date: Mon, 26 Oct 2009 23:33:51 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091027011310.C49266BE612@mercury.lcs.mit.edu>
References: <20091027011310.C49266BE612@mercury.lcs.mit.edu>
Message-ID: <4AE66A1F.9000305@bennett.com>
I agree with about all of this, and would simply note that I don't know
most of the people on this list well enough to say who's an angry old
hippie and who isn't, not that it matters. An awful lot of the net neut
issue is rehashing grievances against the defunct monopoly phone
companies, which is all fine if one is into that sort of thing, just not
quite relevant to the world we live in today.
Noel Chiappa wrote:
> > From: Richard Bennett
>
> >> It seems to me that the 'end-end design ideas' have gotten mixed up in
> >> what is, at the bottom, a fight over how to divide up the economic pie
> >> of communication networks.
>
> > You mean the end-to-end design ideas have gotten mixed up in a fight
> > over not changing how the economic pie is currently divided.
>
> Err, 'the current division pattern' is one of the possible answers to the
> question 'how should the economic pie of communication networks be divided
> up', I would have thought. But this is not important, let me move on...
>
>
> > End-to-End Args proposes applying the notion of smart, reliable
> > endpoints communicating over unreliable comms system to all sorts of
> > other things as a rhetorical trick.
>
> 'Distributed systems' is a long-standing area of interest in computing
> 'science' (but that's a different rathole), and it covers a far larger field
> than simply communication networks (which is the subject area in which the
> end-end analysis originated).
>
> The design philosophy framework discussed in "End-to-End Arguments", while
> originating in an analysis of communication networks, can viably be applied
> to a wide variety of distributed systems (say, for instance, a distributed
> file system which uses replication for robustness and performance). Calling
> the application to such a system, in the larger problem domain, "a rhetorical
> trick" seems considerably 'over the top' to me.
>
> Moreover, your phraseology above ("End-to-End Args proposes applying the
> notion ... to all sorts of other things as a rhetorical trick") seems to
> imply that a principal feature of the paper are attempts to apply the
> end-to-end argument to places outside the computerized information systems
> domain. In fact, there is only paragraph, in the section entitled "History,
> and application to other system areas" which deals with such examples. That
> hardly qualifies as what your wording implies - which is that such
> expansionary applications are a major thrust of the paper.
>
> You're also incorrect to characterize even that paragraph as "applying the
> notion of smart, reliable endpoints communicating over unreliable comms
> system". The banking example certainly doesn't fit that rubric. It would be
> more apt to describe the examples in that paragraph as examples of "functions
> placed at low levels of a system [which] may be redundant or of little value
> when compared with the cost of providing them at that low level" - that
> phrase, of course, being from the paper's own abstract.
>
>
> > Moors points out that E2E Args never did describe the Internet.
>
> I think this is again a misreprentation of what the Moors paper says - but
> we've been down that rabbit hole before.
>
>
> > 10. Google's MCI vets worry that telcos will put them out of business
> > like they did MCI unless end-to-end is law.
> > 11. Public interest groups push for end-to-end law.
> > 12. FCC asks: "What's wrong with descending into dogma? That's what we do."
>
> Policy and engineering are two very different problem domains, and the former
> is free to ignore the latter, if other external (i.e. non-engineering) factors
> make that the preferable choice. (Within limits, of course; I treat that point
> last.)
>
> Just because an engineering discipline says 'X is the way to go', that
> doesn't mean policy has to follow. As a made-up example, country Y might
> decide that for non-engineering reasons, they prefer to ban gas turbines as
> aircraft engines, in favour of piston engines (perhaps because they don't
> like the high-pitched whine of turbines, say). However, clearly, if country Y
> communally makes the decision to ban gas turbines, that's their call - even
> at the same time that it remains a non-optimal decision from an _engineering_
> perspective.
>
> The interesting question, of course, is whether it's good public policy to
> make policy choices that are a non-optimal decision from an engineering
> perspective. Clearly in cases where that is done there will be a price to pay
> (e.g. in the example above, slower planes, and higher fuel consumption), but
> only the community in question can decide if those costs are worth the
> benefits (e.g. getting rid of turbine whine). There is no general principle
> one can apply in such cases, to decide whether or not to follow the optimal
> engineering path; each will have to be decided on the overall merits.
>
> So if some factions are calling for an 'end-to-end law' (whatever that might
> be - my opinion would be that that is a poor name, although I can see where
> it came from), that's a legitimate policy position, on a legitimate policy
> decision. Engineering can only provide data to that debate, as to whether
> it's the most efficient choice, or not - as in the gas turbine example.
>
> The one place policy _cannot_ go is to _ignore hard constraints_. As Feynman
> so elegantly put it (in his appendix to the 'Challenger' crash report'):
>
> "For a successful technology, reality must take precedence over public
> relations, for nature cannot be fooled."
>
>
> > 13. Angry old hippies go "Right on, FCC, your daddy's Internet is good
> > enough for you!"
>
> The implication here seems to be that people who advocate a certain position
> on how to divide up the network pie are also associated with a certain place
> on the political spectrum - at least, in terms of their views on economics?
>
> (Those who know me will no doubt be as amused as I am by the seeming
> supposition that I might fall into this imaginary category - but I digress.)
>
> I haven't actually stated here anything about my views on how to divide up the
> network money pie. Actually, I don't really care about that issue: although I
> do have views on what kind of service model the network should offer, they are
> driven by other factors, such as engineering.
>
>
> All of which should serve to make several points that everyone should retain -
> that discussing whether or not the End-to-End princple is a good/valid
> engineering point is separate from the question of what service model the
> network should offer to its customers - and that people can have positions on
> that latter question which are utterly not a result of their views (if any) on
> the issue of how to divide up the network pie.
>
> Some consequences in the latter will obviously be a _result_ of their position
> on the service model, of course, but it should be noted that the effects on
> the pie division are a _result_ of their position on the service model issue,
> not the _cause_ of the latter - seemingly unlike that for some other people.
>
> Noel
>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From Jon.Crowcroft at cl.cam.ac.uk Tue Oct 27 00:35:36 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Tue, 27 Oct 2009 07:35:36 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE66A1F.9000305@bennett.com>
References: <20091027011310.C49266BE612@mercury.lcs.mit.edu>
<4AE66A1F.9000305@bennett.com>
Message-ID:
In missive <4AE66A1F.9000305 at bennett.com>, Richard Bennett typed:
>>hippie and who isn't, not that it matters. An awful lot of the net neut
>>issue is rehashing grievances against the defunct monopoly phone
>>companies, which is all fine if one is into that sort of thing, just not
>>quite relevant to the world we live in today.
yes but...
it was relevant _again_ for a while because of cellular phone
companies reluctance to do anything interesting in the
internet-stylee, but after the iPhone did an end-run on
them, and android and half-dozen other smart phone
systems moved to an end-system app market independent
of provider, that problem went away...
for a while, i thought that ISPs might be evolving into
telcos too (its part of the territory)- but this
recent nanog talk encouraged me:
http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_Ob
serveReport_N47_Mon.pdf
btw, the "old hippie" tag is a bit off in terms of age and
location for some of us....for example, I'm a card carrying
london ex punk:)
(read "memoirs of a geezer" by jah wobble,
and you'll see that we are
closer in ethos to yippees, seein as we don't subscribe to
liberalism)
j.
From dpreed at reed.com Tue Oct 27 06:32:35 2009
From: dpreed at reed.com (David P. Reed)
Date: Tue, 27 Oct 2009 09:32:35 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com>
Message-ID: <4AE6F673.8080807@reed.com>
Is it the "aging" part or the "hippie" part that makes a person suspect?
I could give you a list of labels that have been applied to me, in
discussions of network technology, to conjure with as you like:
corporate-type, libertarian, communist, hippie, net-nutter, past-it,
ivory-tower, propellerhead, mere engineer, non-economist, naive,
fuzzy-minded, ...
I personally don't think such labels make a whit of difference.
In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the
first four A's on the list of memberships. Does that make a difference?
It turns out that one of my ancestors (John Reed) arrived in Rhode
Island in 1615, and another came to the US on Ellis Island. One of my
ancestors was at the battle of Lexington and Concord, and another was a
Gibson Girl on 42nd street, having immigrated into the country. My
father can be seen in documentary footage shot on the USS Missouri
during the Korean Conflict, and was in charge of designing many of the
modern US Navy ships now in service.
Do those things make a difference?
I guess the fellow who is responsible for WiFi and UWB knows how to
judge ideas by the person's lifestyle.
And by the way, I'm neither aging (I'm 57, and can beat most people in
arm-wrestling, if nothing else), nor a classic "hippie" (my views in
those days tended toward a very different direction - a mixture of
systems design, AI, and math, mixed with stopping the Vietnam War and
creating a free market of ideas).
But so what if I were?
From Jon.Crowcroft at cl.cam.ac.uk Tue Oct 27 07:43:15 2009
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Tue, 27 Oct 2009 14:43:15 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE6F673.8080807@reed.com>
References: <20091027011310.C49266BE612@mercury.lcs.mit.edu>
<4AE66A1F.9000305@bennett.com>
<4AE6F673.8080807@reed.com>
Message-ID:
I may fall down on relevance
(c.f. Deirdre Wilson & Dan Sperberr Relevance Theory, 1985)
but I think I am going to have to refer you to youtube:
http://www.youtube.com/watch?v=2SNHtKfDxlg
but anyhow, I suspect I am just as suspect as you
for what its worth...
this has to be set against the rabid free market libertarianism
fairly common in Internet Research circles from 1992 until the present
day, which is also extremely unrepresentative of the world...
In missive <4AE6F673.8080807 at reed.com>, "David P. Reed" typed:
>>Is it the "aging" part or the "hippie" part that makes a person suspect?
>>I could give you a list of labels that have been applied to me, in
>>discussions of network technology, to conjure with as you like:
>>
>>corporate-type, libertarian, communist, hippie, net-nutter, past-it,
>>ivory-tower, propellerhead, mere engineer, non-economist, naive,
>>fuzzy-minded, ...
>>
>>I personally don't think such labels make a whit of difference.
>>
>>In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the
>>first four A's on the list of memberships. Does that make a difference?
>>
>>It turns out that one of my ancestors (John Reed) arrived in Rhode
>>Island in 1615, and another came to the US on Ellis Island. One of my
>>ancestors was at the battle of Lexington and Concord, and another was a
>>Gibson Girl on 42nd street, having immigrated into the country. My
>>father can be seen in documentary footage shot on the USS Missouri
>>during the Korean Conflict, and was in charge of designing many of the
>>modern US Navy ships now in service.
>>
>>Do those things make a difference?
>>
>>I guess the fellow who is responsible for WiFi and UWB knows how to
>>judge ideas by the person's lifestyle.
>>
>>And by the way, I'm neither aging (I'm 57, and can beat most people in
>>arm-wrestling, if nothing else), nor a classic "hippie" (my views in
>>those days tended toward a very different direction - a mixture of
>>systems design, AI, and math, mixed with stopping the Vietnam War and
>>creating a free market of ideas).
>>
>>But so what if I were?
cheers
jon
From richard at bennett.com Tue Oct 27 14:27:31 2009
From: richard at bennett.com (Richard Bennett)
Date: Tue, 27 Oct 2009 14:27:31 -0700
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To:
References: <20091027011310.C49266BE612@mercury.lcs.mit.edu> <4AE66A1F.9000305@bennett.com>
<4AE6F673.8080807@reed.com>
Message-ID: <4AE765C3.1090303@bennett.com>
Seems to me that the real hippies were pretty much libertarians who
didn't trust The Man's Government any more than The Man's Corporations.
Internet Research circles are interesting, in that they consist of
people taking money from The Man's War Machine to spread peace, love,
and understanding, which may be the best form of national defense anyhow.
And in plain engineering circles, there seems to be a divide between
libertarians who don't trust authority period and socialists who view
society as a machine to be optimized and markets as too messy an
inefficient for the purpose. Of course, socialism is inconsistent with
net neutrality in principle, but nobody really understands that.
In the course of reading the 1984 version of E2E Args, I was struck by
the mention of RISC. It's interesting because back in the 1970s and 80s,
there was this general train of thought about building reliable, high
quality systems on cheap and plentiful unreliable parts. It was
interesting because it seemed to resolve the "good, fast, cheap: pick
any two" dilemma that I used to see above programmers' desks from about
1980 on. RAID, RISC, datagrams, old-fashioned CSMA/CD Ethernet, and
massively parallel microprocessor-based supercomputers were all
explorations of that idea, which worked out well in some contexts and
less well in others. RISC was a bust, for example, and while datagrams
are good for content-oriented network applications, they're obviously
less good for real-time network apps, and Ethernet only became dominant
when we dumped CSMA/CD for the collision-free, flow controlled, full
duplex switches that we use today. So why is it that you can build a
nice system using crappy parts in some cases and not in others?
Perhaps the constraint is time, and these systems didn't get all three
of "good, fast, cheap" but only good and cheap. If that's the case, it
places a boundary on how far you can go with an E2E model in large-scale
networks. People want to use the Internet as more than a content network
these days, because interpersonal communication is the real killer app
for networking, and that takes QoS, and you can't do QoS E2E.
Public policy needs to be constrained by engineering, as Noel said, but
the engineering needs to be good, not ideological.
RB
Jon Crowcroft wrote:
> I may fall down on relevance
> (c.f. Deirdre Wilson & Dan Sperberr Relevance Theory, 1985)
> but I think I am going to have to refer you to youtube:
>
> http://www.youtube.com/watch?v=2SNHtKfDxlg
>
> but anyhow, I suspect I am just as suspect as you
> for what its worth...
>
> this has to be set against the rabid free market libertarianism
> fairly common in Internet Research circles from 1992 until the present
> day, which is also extremely unrepresentative of the world...
>
> In missive <4AE6F673.8080807 at reed.com>, "David P. Reed" typed:
>
> >>Is it the "aging" part or the "hippie" part that makes a person suspect?
>
> >>I could give you a list of labels that have been applied to me, in
> >>discussions of network technology, to conjure with as you like:
> >>
> >>corporate-type, libertarian, communist, hippie, net-nutter, past-it,
> >>ivory-tower, propellerhead, mere engineer, non-economist, naive,
> >>fuzzy-minded, ...
> >>
> >>I personally don't think such labels make a whit of difference.
> >>
> >>In fact, I am a member of AAAS, AARP, ACLU, ACM, and that's only the
> >>first four A's on the list of memberships. Does that make a difference?
> >>
> >>It turns out that one of my ancestors (John Reed) arrived in Rhode
> >>Island in 1615, and another came to the US on Ellis Island. One of my
> >>ancestors was at the battle of Lexington and Concord, and another was a
> >>Gibson Girl on 42nd street, having immigrated into the country. My
> >>father can be seen in documentary footage shot on the USS Missouri
> >>during the Korean Conflict, and was in charge of designing many of the
> >>modern US Navy ships now in service.
> >>
> >>Do those things make a difference?
> >>
> >>I guess the fellow who is responsible for WiFi and UWB knows how to
> >>judge ideas by the person's lifestyle.
> >>
> >>And by the way, I'm neither aging (I'm 57, and can beat most people in
> >>arm-wrestling, if nothing else), nor a classic "hippie" (my views in
> >>those days tended toward a very different direction - a mixture of
> >>systems design, AI, and math, mixed with stopping the Vietnam War and
> >>creating a free market of ideas).
> >>
> >>But so what if I were?
>
> cheers
>
> jon
>
>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From davide+e2e at cs.cmu.edu Tue Oct 27 19:57:38 2009
From: davide+e2e at cs.cmu.edu (Dave Eckhardt)
Date: Tue, 27 Oct 2009 22:57:38 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE765C3.1090303@bennett.com>
Message-ID: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
> [...] Ethernet only became dominant when we dumped CSMA/CD for
> the collision-free, flow controlled, full duplex switches that
> we use today.
In the two environments I'm familiar with, Ethernet had firmly
crowded out everything else (and there were other things: IBM
Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet,
etc.) when it was still half-duplex thin-net, which was replaced
by 10-megabit twisted-pair into hubs, *then* 100-megabit
twisted-pair into switches.
I think there were a lot of places where Ethernet was dominant
before switches... though maybe we're using different definitions
of "dominant"? I think I mean something like "more than 90% of
desktops".
Dave Eckhardt
From richard at bennett.com Tue Oct 27 23:34:45 2009
From: richard at bennett.com (Richard Bennett)
Date: Wed, 28 Oct 2009 02:34:45 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
Message-ID: <4AE7E605.7010600@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/89cc429f/attachment.html
From dhc2 at dcrocker.net Wed Oct 28 03:44:23 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 28 Oct 2009 06:44:23 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
Message-ID: <4AE82087.4040202@dcrocker.net>
Dave Eckhardt wrote:
>> [...] Ethernet only became dominant when we dumped CSMA/CD for
>> the collision-free, flow controlled, full duplex switches that
>> we use today.
>
> In the two environments I'm familiar with, Ethernet had firmly
> crowded out everything else (and there were other things: IBM
> Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet,
> etc.) when it was still half-duplex thin-net, which was replaced
> by 10-megabit twisted-pair into hubs, *then* 100-megabit
> twisted-pair into switches.
Yup. "Ethernet" collision-free switches came quite a bit after real ethernet
dominated LANs.
(The quotations are because the former presents an Ethernet interface but not
Ethernet over the wire. Thicknet, thin-net, and I believe the original versions
of twisted-pair, all used had the shared-access, collision-capable ethernet over
the wire.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
From dpreed at reed.com Wed Oct 28 05:13:40 2009
From: dpreed at reed.com (David P. Reed)
Date: Wed, 28 Oct 2009 08:13:40 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE7E605.7010600@bennett.com>
References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
<4AE7E605.7010600@bennett.com>
Message-ID: <4AE83574.2050801@reed.com>
On 10/28/2009 02:34 AM, Richard Bennett wrote:
> CSMA/CD Ethernet was simply a best-efforts LAN, but switched Ethernet
> is a QoS-capable WAN and facilities fabric as well; ever seen an
> Internet Exchange Point? Big fat Ethernet switches sit at the heart
> of them, passing multiple packets at a time in parallel. It's a whole
> different concept of networking than the fat dumb pipe.
>
If I had seen an Internet Exchange point, what would looking at racks,
cables, power supplies, etc. tell me exactly?
And since the word "dumb pipe" is a construct largely used by operators
who use it to describe a "business model", and to explain the Internet
to Ted Stevens as a "series of tubes" but "not a dump-truck," what
contribution to Internet architecture is being made by this idiotic
thread now that Bennett has hooked people into his trolling rig?
"whole different kind of networking" is a really useful description -
it's up there with "carrier-grade" as a marketing concept that has no
content.
Bennett is *paid* by ITIF to throw out these kinds of statements,
calculated to get someone to extend a conversational diversion. He is
not contributing technically on this list which is about technology and
architectural *research*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/29ebfeae/attachment.html
From jtk at depaul.edu Wed Oct 28 05:21:20 2009
From: jtk at depaul.edu (John Kristoff)
Date: Wed, 28 Oct 2009 07:21:20 -0500
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE82087.4040202@dcrocker.net>
References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
<4AE82087.4040202@dcrocker.net>
Message-ID: <20091028122120.GA27331@condor.depaul.edu>
On Wed, Oct 28, 2009 at 06:44:23AM -0400, Dave CROCKER wrote:
> >etc.) when it was still half-duplex thin-net, which was replaced
> >by 10-megabit twisted-pair into hubs, *then* 100-megabit
> >twisted-pair into switches.
>
> Yup. "Ethernet" collision-free switches came quite a bit after real
> ethernet dominated LANs.
10 Mb/s Etherhet LAN switches arrived even before 100 Mb/s Ethernet
was available, largely thanks to Kalpana (eventually bought by Cisco).
In addition to hubs and other reasons, switches really helped answer
criticisms of competing technologies such as Token Ring, eventually
leading to Ethernet becoming the RS-232 of LAN technology.
John
From jnc at mercury.lcs.mit.edu Wed Oct 28 07:44:34 2009
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 28 Oct 2009 10:44:34 -0400 (EDT)
Subject: [e2e] Protocols breaking the end-to-end argument
Message-ID: <20091028144434.8BE676BE583@mercury.lcs.mit.edu>
> From: Dave CROCKER
> The quotations are because the former presents an Ethernet interface
> but not Ethernet over the wire.
Thereby becoming a perfect illustration of the systems architecture truism
that _interfaces_ between subsystems are far more persistent (lifetime-wise)
than the internals of the subsystem.
Other examples of this phenomenon include the RJ-11 phone jack (both
physically and electrically), the standard screw-in light bulb socket (now
hosting those fluorescent spiral tube bulbs), etc, etc.
Noel
From davide+e2e at cs.cmu.edu Wed Oct 28 08:09:05 2009
From: davide+e2e at cs.cmu.edu (Dave Eckhardt)
Date: Wed, 28 Oct 2009 11:09:05 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091028122120.GA27331@condor.depaul.edu>
Message-ID: <21118.1256742545@lunacy.ugrad.cs.cmu.edu>
> 10 Mb/s Etherhet LAN switches arrived even before 100 Mb/s
> Ethernet was available, largely thanks to Kalpana (eventually
> bought by Cisco).
The original claim used (without definition) the word "dominant".
I proposed (without objection so far) the definition "90% of
desktops". My counter-claim is that Ethernet was dominant (90%
of desktops) without the arrival of switches having been the
cause. The existence of a small number of 10-megabit switches
doesn't force acceptance of one causal claim over the other.
So how about this update: "Ethernet was serving 90% of desktops
before 50% of those desktops were talking to switches"?
Dave Eckhardt
From davide+e2e at cs.cmu.edu Wed Oct 28 08:12:35 2009
From: davide+e2e at cs.cmu.edu (Dave Eckhardt)
Date: Wed, 28 Oct 2009 11:12:35 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE7E605.7010600@bennett.com>
Message-ID: <21130.1256742755@lunacy.ugrad.cs.cmu.edu>
>> I think there were a lot of places where Ethernet was dominant
>> before switches... though maybe we're using different definitions
>> of "dominant"? I think I mean something like "more than 90% of
>> desktops".
> CSMA/CD Ethernet was simply a best-efforts LAN, but switched
> Ethernet is a QoS-capable WAN and facilities fabric as well;
> ever seen an Internet Exchange Point? Big fat Ethernet switches
> sit at the heart of them, passing multiple packets at a time
> in parallel. It's a whole different concept of networking than
> the fat dumb pipe.
I don't understand how your comment is a response to the testable
claim I made in response to your incompletely specified claim.
Dave Eckhardt
From Maha.Abdallah at lip6.fr Tue Oct 27 06:14:39 2009
From: Maha.Abdallah at lip6.fr (Maha Abdallah)
Date: Tue, 27 Oct 2009 14:14:39 +0100
Subject: [e2e] NetGames 2009 - Call for Participation (Nov. 23-24 - Paris,
France)
Message-ID: <47983aa62688c1c5861bf42c6177ff0e.squirrel@mailtwo.lip6.fr>
CALL FOR PARTICIPATION
**************************************************************************
* NetGames 2009 *
* The 8th Annual Workshop on Network and Systems Support for Games *
* November 23-24, 2009 *
* Paris , France *
* *
* In co-operation with ACM SIGCOMM and ACM SIGMM *
* Technically sponsored by IEEE Communications Society *
* *
* Early registration deadline: Nov 8, 2009 *
* http://netgames2009.lip6.fr/ *
**************************************************************************
We would like to cordially invite you to attend the 8th Annual Workshop on
Network and Systems Support for Games (NetGames 2009), which will be held
on November 23-24, 2009 in Paris, France.
KEYNOTE SPEAKERS
================
Two exciting keynote talks will be given by distinguished speakers with
tremendous experience in networked games and virtual environments:
1. Dr. Michael Macedonia (Vice President and General Manager, Forterra
Federal Systems)
Title: Next Generation Virtual Worlds
2. Dr. R?mi Arnaud (Chief Software Architect, Screampoint International)
Title: Trends in 3D technologies and the impact on networked games
OVERVIEW
========
The NetGames workshop is a major annual international workshop that brings
together researchers and visionaries from academia, research labs, and
industry to present new research in understanding networked games of today
and in enabling the next generation of them. NetGames has become a
recognized venue for Promoting exciting discussions among its participants
in all areas related to online games and Virtual environments.
Two keynotes addresses, and a total of 18 research papers, posters and
demos spanning various topics related to networked games will be presented
and discussed. We cordially invite you to attend the workshop and share
with us your feedback, thoughts, and experience. Further details can be
found at: http://netgames2009.lip6.fr/
ACCEPTED PAPERS
===============
A. Full papers:
------------
Measurement and Analysis of World of Warcraft in Mobile WiMAX Networks
Xiaofei Wang (Seoul national university, KR)
Hyun-chul Kim (Seoul National University, KR)
Taekyoung Kwon (Seoul National University, KR)
Yanghee Choi (Seoul National University, KR)
Sunghyun Choi (Seoul National University, KR)
Jang Hanyoung (XRONet Corporation, KR)
802.11 Wireless LAN Multiplayer Game Capacity and Optimization
Hanghang Qi (Hamilton Institute, NUIM, IE)
David Malone (NUI Maynooth, IE)
Dimitri D Botvich (Waterford Institute of Technology, IE)
Hack, Slash, and Chat: A study of players? behavior and communication in
MMORPGs
Mirko Su?njevic (University of Zagreb, HR)
Ognjen Dobrijevic (University of Zagreb, HR)
Maja Matijasevic (University of Zagreb, HR)
Peer NAT Proxies for Peer-to-Peer Applications
Daryl Seah (National University of Singapore, SG)
Wai Kay Leong (National University of Singapore, SG)
Qingwei Yang (National University of Singapore, SG)
Ben Leong (National University of Singapore, SG)
Razeen Ali (National University of Singapore, SG)
Distributed Avatar Management for Second Life
Matteo Varvello (Eurecom - Thomson, FR)
Stefano Ferrari (Politecnico di torino, IT)
Ernst W Biersack (EURECOM, FR)
Christophe Diot (Thomson, FR)
PlayerRating: A Reputation System for Multiplayer Online Games
Ed Kaiser (Portland State University, US)
Wu-chang Feng (Portland State University, US)
Avatar movement in World of Warcraft Battlegrounds
John L. Miller (Microsoft Research, Cambridge, UK)
Jon Crowcroft (University of Cambridge, UK)
The Impact of Virtualization on the Performance of Massively Multiplayer
Online Games
Vlad Nae (University of Innsbruck, AT)
Alexandru Iosup (Delft University of Technology, NL)
Radu Prodan (University of Innsbruck, AT)
Thomas Fahringer (University of Innsbruck, AT)
Evaluating Ginnungagap: a middleware for migration of partial game-state
utilizing core-selection for latency reduction
Paul B Beskow (Simula Research Laboratory, NO)
Geir Erikstad (Simula Research Laboratory/University of Oslo, NO)
P?l Halvorsen (Simula Research Laboratory, NO)
Carsten Griwodz (Simula Research Laboratory, NO)
Bandwidth-Aware Peer-to-Peer 3D Streaming
Chien-Hao Chien (National Central University, TW)
Shun-Yun Hu (National Central University, TW)
Jehn-Ruey Jiang (National Central University, TW)
B. Posters & Demos:
----------------
FizzX: Multiplayer Time Manipulation in Networked Games
Colin Towle (University of Ottawa, CA)
Pascal Proulx (University of Ottawa, CA)
Saurabh Ratti (University of Ottawa, CA)
Shervin Shirmohammadi (University of Ottawa, CA)
Transparency Analysis and Haptic Synchronization for Transparency of
Force-reflecting Teleoperation
Seokhee Lee (Gwangju Institute of Science and Technology, KR)
Yutaka Ishibashi (Nagoya Institute of Technology, JP)
JongWon Kim (GIST (Gwangju Institute of Science & Technology), KR)
AOI cast by Tolerance Based Compass Routing in Distributed Virtual
Environments
Michele Albano (University of Pisa, IT)
Luca Genovali (IMT, IT)
Antonio Quartulli (University of Trento, IT)
Laura Ricci (University of Pisa, IT)
Peer-to-Peer Support for Low-Latency Massively Multiplayer Online Games in
the Cloud
Richard S?selbeck (University of Mannheim, DE)
Gregor A Schiele (University of Mannheim, DE)
Christian Becker (Universit?t Mannheim, DE)
Player-Customized Puzzle Instance Generation for Massively Multiplayer
Online Games
Alexandru Iosup (Delft University of Technology, NL)
On Prophesying Online Gamer Departure
Pin-Yun Tarng (National Taiwan University, TW)
Kuan-Ta Chen (Academia Sinica, TW)
Polly Huang (National Taiwan University, TW)
Capturing and Storing Profile Information for Gamers Playing Multiplayer
Online Games
Tomas Hildebrandt (TU Darmstadt, DE)
Sonja Bergstr??er (Technical University of Darmstadt, DE)
Christoph Rensing (Technical University of Darmstadt, DE)
Ralf Steinmetz (Technische Universitaet Darmstadt, DE)
Interconnection of Game Worlds and Physical Environments in Educational
Settings
Raphael Zender (University of Rostock, DE)
Ulrike Lucke (University of Rostock, DE)
Dennis Maciuszek (University of Rostock, DE)
Alke Martens (University of Rostock, DE)
From dhc2 at dcrocker.net Wed Oct 28 09:23:47 2009
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 28 Oct 2009 12:23:47 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <20091028144434.8BE676BE583@mercury.lcs.mit.edu>
References: <20091028144434.8BE676BE583@mercury.lcs.mit.edu>
Message-ID: <4AE87013.8080201@dcrocker.net>
Noel Chiappa wrote:
> Thereby becoming a perfect illustration of the systems architecture truism
> that _interfaces_ between subsystems are far more persistent (lifetime-wise)
> than the internals of the subsystem.
>
> Other examples of this phenomenon include the RJ-11 phone jack (both
> physically and electrically), the standard screw-in light bulb socket (now
> hosting those fluorescent spiral tube bulbs), etc, etc.
A particularly fun example of this is RFC 1001/1002, which re-implemented
NetBIOS. Preserve the IBM API, but use TCP protocols. (There had been a couple
of proprietary non-IBM TCP versions earlier; this created a standard.)
Had IBM published the underlying protocols, the TCP version would no doubt have
been quite different.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
From richard at bennett.com Wed Oct 28 20:09:11 2009
From: richard at bennett.com (Richard Bennett)
Date: Wed, 28 Oct 2009 23:09:11 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <21118.1256742545@lunacy.ugrad.cs.cmu.edu>
References: <21118.1256742545@lunacy.ugrad.cs.cmu.edu>
Message-ID: <4AE90757.2090405@bennett.com>
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091028/63a2fa10/attachment.html
From richard at bennett.com Wed Oct 28 20:15:48 2009
From: richard at bennett.com (Richard Bennett)
Date: Wed, 28 Oct 2009 23:15:48 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE87013.8080201@dcrocker.net>
References: <20091028144434.8BE676BE583@mercury.lcs.mit.edu>
<4AE87013.8080201@dcrocker.net>
Message-ID: <4AE908E4.6020208@bennett.com>
I had personally seen the source code to the IBM/Sytek protocols, under
NDA, for NETBIOS/SMB before RFC 1001/2 were written, which is one reason
I could only be a cheerleader for 1001/2. At Tandem we implemented an
SMB server under the T16's Guardian OS. SMB wasn't too hard to reverse
engineer, as the SAMBA guys found out; the IBM PC Network was harder, so
we used a PC with both PC Network and Ethernet cards as a bridge.
Dave CROCKER wrote:
>
>
> Noel Chiappa wrote:
>> Thereby becoming a perfect illustration of the systems architecture
>> truism
>> that _interfaces_ between subsystems are far more persistent
>> (lifetime-wise)
>> than the internals of the subsystem.
>>
>> Other examples of this phenomenon include the RJ-11 phone jack (both
>> physically and electrically), the standard screw-in light bulb socket
>> (now
>> hosting those fluorescent spiral tube bulbs), etc, etc.
>
>
> A particularly fun example of this is RFC 1001/1002, which
> re-implemented NetBIOS. Preserve the IBM API, but use TCP protocols.
> (There had been a couple of proprietary non-IBM TCP versions earlier;
> this created a standard.)
>
> Had IBM published the underlying protocols, the TCP version would no
> doubt have been quite different.
>
> d/
>
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From william.allen.simpson at gmail.com Thu Oct 29 01:29:31 2009
From: william.allen.simpson at gmail.com (William Allen Simpson)
Date: Thu, 29 Oct 2009 04:29:31 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE82087.4040202@dcrocker.net>
References: <18710.1256698658@lunacy.ugrad.cs.cmu.edu>
<4AE82087.4040202@dcrocker.net>
Message-ID: <4AE9526B.7050306@gmail.com>
Dave CROCKER wrote:
> Dave Eckhardt wrote:
>> Richard Bennett wrote:
>>> [...] Ethernet only became dominant when we dumped CSMA/CD for
>>> the collision-free, flow controlled, full duplex switches that
>>> we use today.
>>
>> In the two environments I'm familiar with, Ethernet had firmly
>> crowded out everything else (and there were other things: IBM
>> Token Ring, Corvus OmniNet, AppleTalk over PhoneNet, LattisNet,
>> etc.) when it was still half-duplex thin-net, which was replaced
>> by 10-megabit twisted-pair into hubs, *then* 100-megabit
>> twisted-pair into switches.
>
> Yup. "Ethernet" collision-free switches came quite a bit after real
> ethernet dominated LANs.
>
Agreed, as to multi-point LAN technology, but only after circa 1990. One
of the environments that I wrestled with during the '80s was considered
the largest thicknet installation in the world. But even then, terminals,
computers, and entire facilities were primarily connected with one or
more variants of a poll-select protocol over RS-232. There were usually
two serial connectors on every machine (with no ethernet at all).
Even today, there are *far* more point-to-point WAN links than ethernet.
I have the advantage of working on far more than 2 facilities. Token
ring and related were never more than fragile and overpriced disasters.
The market spoke, even when big industry was trying to force them down
our throats.
The pedant that interrupted this thread appears to be fairly clueless
about real deployment. And his economic analysis is ... ill-informed.
Perhaps that's a reason that IEEE 802 development in general was so
conservative and poorly done.
From davide+e2e at cs.cmu.edu Thu Oct 29 11:05:58 2009
From: davide+e2e at cs.cmu.edu (Dave Eckhardt)
Date: Thu, 29 Oct 2009 14:05:58 -0400
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <4AE90757.2090405@bennett.com>
Message-ID: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
> It strikes me that your 90% claim is a bit of an exaggeration,
> and more importantly that it misses the point.
Actually, I was trying to get you to define what you meant by
"Ethernet became dominant" by proposing a definition, since
you hadn't.
> Define "the market" as all the places where switched Ethernet
> is used today, crank in some realistic shares, and tell me
> what you get; by guess is that coax Ethernet was deployed in
> around 10-20% of the places where twisted pair and optical
> Ethernet LANs, MANs, and WANs are used today
Now I get it: when you wrote "Ethernet only became dominant
when we dumped CSMA/CD for the collision-free, flow controlled,
full duplex switches that we use today" you meant something
like "Switches were a necessary addition to Ethernet before
it could grow from a single-building LAN to a campus-spanning
technology". I buy that, because treating an entire campus
or medium-sized company as one collision domain wouldn't have
worked out very well.
On the other hand...
> ARCNet was very big in desktop connections, as far as that
> goes, especially in IBM shops because it used the 3270 PHY.
I don't think any of Ethernet's competitors would have scaled
very well either--ARCNet had single-byte node addresses; Token
Ring would have been painful if you had to share a transmit
token with thousands of other machines; etc. So it's unclear
that CSMA/CD was a structural limit of Ethernet--the reality
is probably more like "It doesn't matter much how you contend
among a few hosts, but you can't build large networks unless
you limit contention domains to less than the size of the
large network", which is almost a tautology.
Dave Eckhardt
From L.Wood at surrey.ac.uk Thu Oct 29 12:43:17 2009
From: L.Wood at surrey.ac.uk (Lloyd Wood)
Date: Thu, 29 Oct 2009 19:43:17 +0000
Subject: [e2e] Protocols breaking the end-to-end argument
In-Reply-To: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
Message-ID:
On 29 Oct 2009, at 18:05, Dave Eckhardt wrote:
> > Define "the market" as all the places where switched Ethernet
>> is used today, crank in some realistic shares, and tell me
>> what you get; by guess is that coax Ethernet was deployed in
>> around 10-20% of the places where twisted pair and optical
>> Ethernet LANs, MANs, and WANs are used today
>
> Now I get it: when you wrote "Ethernet only became dominant
> when we dumped CSMA/CD for the collision-free, flow controlled,
> full duplex switches that we use today" you meant something
> like "Switches were a necessary addition to Ethernet before
> it could grow from a single-building LAN to a campus-spanning
> technology". I buy that, because treating an entire campus
> or medium-sized company as one collision domain wouldn't have
> worked out very well.
Never mind that.
Two anecdotes from the early days of my comparatively
late PhD studies (1996 or so):
1. The networks lab was next to the artificial intelligence
lab. The AI students were cooler than we were; they dressed
better, had more funding, and had laptop computers. But,
in connecting the laptops to the Ethernet LAN, they didn't
care how a big shared Ethernet coax LAN worked. They'd
just hook up connections any old how, T off more coax,
disconnect when they were done... and often they'd bring
the network down, usually just before they locked up and
took their laptops home for the day.
Never mind collisions. Ethernet switches were necessary
just to protect against and isolate the users.
2. Everyone in networks was working on ATM, and talking
about the Next Big Thing: 25Mbps ATM to the desktop.
I kept looking at the 10Mbps Ethernet we were already
using all the time every day along with the TCP/IP
stack to do daily work on and send emails about ATM,
thinking "Something is wrong with this picture."
L.
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
From touch at ISI.EDU Fri Oct 30 15:45:25 2009
From: touch at ISI.EDU (Joe Touch)
Date: Fri, 30 Oct 2009 15:45:25 -0700
Subject: [e2e] a note about some ad hominem attacks
Message-ID: <4AEB6C85.3050007@isi.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, all,
I sent out a few notes off-list direct to those whose posts included
what could be considered ad hominem attacks.
As a reminder, such behavior on this list is a quick ticket to having
your posts held for administrative review - which means (at best) once
daily, with a 24-hour lag.
To be safe, please avoid any claims or judgments about individuals.
Joe (as list admin)
PS - Anyone who feels personally slighted can send me a note off-list,
and I'll evaluate the post and send them a warning if deemed appropriate
and not already sent.
PPS - If you've received more than one of these notes (as I'm catching
up), consider yourself on *very* thin ice.
PPPS - If you didn't yet receive a note, don't assume you haven't
exhibited poor behavior.
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkrrbIUACgkQE5f5cImnZrsmxQCguxudtyfyqNeoth+byFuoZ4an
AXAAnixJ+OnsiZ1LFmRdb9gvrrKCmlYV
=Ob11
-----END PGP SIGNATURE-----
From richard at bennett.com Sat Oct 31 14:46:55 2009
From: richard at bennett.com (Richard Bennett)
Date: Sat, 31 Oct 2009 17:46:55 -0400
Subject: [e2e] Switched Ethernet is Not an End-to-End System;
was Protocols breaking the end-to-end argument
In-Reply-To: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
Message-ID: <4AECB04F.8020802@bennett.com>
Dave Eckhardt wrote:
> So it's unclear
> that CSMA/CD was a structural limit of Ethernet--the reality
> is probably more like "It doesn't matter much how you contend
> among a few hosts, but you can't build large networks unless
> you limit contention domains to less than the size of the
> large network", which is almost a tautology.
>
That's part of the story, but the implications of the switched Ethernet
killing off CSMA/CD Ethernet are much larger, and relate the end-to-end
arguments principle. CSMA/CD Ethernet was an end-point managed system
sharing a dump pipe, while switched Ethernet is a system that deploys
intelligence - switching, flow control, buffering, QoS discrimination,
VLANs - inside the network at multiple points. Switched Ethernet is
scalable, manageable, diagnosable, and future-proof, while CSMA/CD
Ethernet is none of these things. So the competition of CSMA/CD and
Active Switching for markets demonstrates something about which approach
to the design of layer 2 networks is superior.
Now the question that this historical fact raises for me is whether we
can draw any implications from the well-settled outcome of the layer 2
tussle for layer 3 and 4 protocols, given the fact that IP is a very
thin abstraction of the Ethernet layer 2 and that TCP is a vehicle for
resolving problems that are typical of the CSMA/CD Ethernet environment;
I offer that as a realistic assessment of the design choices, realizing
that the official story differs from the reality.
In other words: does the success of Switched Ethernet suggest that it's
better to think of network protocols as units of recursion than as
collections of statically-placed functions that operate once and only
once in the lifetime of a packet?
RB
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
From dpreed at reed.com Sat Oct 31 20:04:22 2009
From: dpreed at reed.com (David P. Reed)
Date: Sat, 31 Oct 2009 23:04:22 -0400
Subject: [e2e] Switched Ethernet is Not an End-to-End System;
was Protocols breaking the end-to-end argument
In-Reply-To: <4AECB04F.8020802@bennett.com>
References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu>
<4AECB04F.8020802@bennett.com>
Message-ID: <4AECFAB6.8030705@reed.com>
On 10/31/2009 05:46 PM, Richard Bennett wrote:
> the fact that IP is a very thin abstraction of the Ethernet layer 2
> and that TCP is a vehicle for resolving problems that are typical of
> the CSMA/CD Ethernet environment
This statement is nonsense. IP is not a very thin abstraction of
Ethernet layer 2. IP is carried over many protocols other than the
Ethernet. TCP is an end-to-end protocol for in-order virtual circuit
data delivery, designed to work over IP, and to handle problems that
have nothing to do with CSMA/CD.
> In other words: does the success of Switched Ethernet suggest that
> it's better to think of network protocols as units of recursion than
> as collections of statically-placed functions that operate once and
> only once in the lifetime of a packet?
No. This is also nonsense, and begs the question. Network protocols
have never been described as not "collections of statically-placed
functions that operate once and only once in the lifetime of a packet".
Nor does the "success" of anything in the marketplace suggest how to think.