<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">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.<br>
<br>
So I think what you are looking for is a set of examples that
demonstrate functions that are "best done inside the network".<br>
<br>
If you read the original paper, there is no claim whatever that says
either:<br>
<br>
1) that all functions should be done at the edges. (this radical
proposition, however, is one that guides some of my personal<br>
interests in researching how far one can go. But that's a "Reed
research guideline" not an architecture argument.)<br>
<br>
2) that one should never include optimizations of functions that
must (to be correct) be done at the edges, in the network.<br>
<br>
Yet each interpretation above (and some others) are used occasionally.<br>
<br>
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?<br>
<br>
Congestion *exists* only inside the network, by definition. So it must
be measured in the network. <br>
<br>
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.<br>
<br>
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, ...<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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! <br>
<br>
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. <br>
<br>
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:<br>
<br>
1) against the network itself,<br>
<br>
2) against a particular end host (or hosts).<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
</font><br>
On 10/23/2009 07:47 AM, <a class="moz-txt-link-abbreviated" href="mailto:L.Wood@surrey.ac.uk">L.Wood@surrey.ac.uk</a> wrote:
<blockquote
cite="mid:4835AFD53A246A40A3B8DA85D658C4BE01368B07@EVS-EC1-NODE4.surrey.ac.uk"
type="cite">
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<meta name="Generator"
content="MS Exchange Server version 6.5.7653.38">
<title>RE: [e2e] Protocols breaking the end-to-end argument</title>
<!-- Converted from text/plain format -->
<p><font size="2">Hey, I wrote a chapter of that book...<br>
<br>
Do look into the Bundle Protocol, which ignore the end-to-end<br>
principle and control loops in its design. See our 'Bundle of<br>
Problems' paper for more on this:<br>
<a moz-do-not-send="true"
href="http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/">http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/</a><br>
The Bundle Protocol has similar problems/oversights as LTP-T.<br>
<br>
Carlo Caini's group has drawn parallels between<br>
DTN work and TCP PEPs, pointing out that what TCP PEPs do<br>
on the quiet (break the end-to-end control loop into separate<br>
loops) is what things like bundle hops + convergence layers<br>
or http proxy caches do more explicitly and visibly. See e.g.<br>
his IWSSC'09 paper:<br>
"TCP, PEP and DTN Performance on Disruptive Satellite Channels."<br>
<br>
L.<br>
<br>
<<a moz-do-not-send="true"
href="http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey.ac.uk/Personal/L.Wood/</a>><a class="moz-txt-link-rfc2396E" href="mailto:L.Wood@surrey.ac.uk"><L.Wood@surrey.ac.uk></a><br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:end2end-interest-bounces@postel.org">end2end-interest-bounces@postel.org</a> on behalf of Jaime Mateos<br>
Sent: Fri 2009-10-23 11:26<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:end2end-interest@postel.org">end2end-interest@postel.org</a><br>
Subject: [e2e] Protocols breaking the end-to-end argument<br>
<br>
Hi,<br>
I'm working on a project about the current challenges the Internet is<br>
presenting to the end-to-end argument. I'd be interested to know about<br>
any protocols, currently in use, that break the end-to-end principle and<br>
the context where they are used. So far the only one I've found is TCP<br>
PEP that seems to be in use in satellite networks (Internetworking and<br>
computing over satellite networks, Yongguang Zhang -<br>
<a class="moz-txt-link-freetext" href="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">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</a>)<br>
<br>
<br>
There also seems to be a number of research projects such as Split TCP<br>
and LTP-T that I've come across. I'm also interested in these but not to<br>
the same degree as in protocols that are currently in use today.<br>
<br>
Thanks,<br>
Jaime Mateos<br>
<br>
<br>
</font>
</p>
</blockquote>
</body>
</html>