[e2e] E2E vs. LL Reliability [e2e principle..where??....]
Reiner.Ludwig at Ericsson.com
Tue Jun 19 00:50:37 PDT 2001
this reply comes a bit late, but nevertheless ...
At 20:47 02.06.01, David P. Reed wrote:
>Now the end-to-end argument is often correctly applied to argue against
>certain "hop by hop" functions (like link-level security and link-level
>reliability functions, which are often suggested on the basis that they
>are "more efficient" than source-destination encryption and
>source-destination error correction).
I'm a big fan of the "E2E Argument" paper myself, but in the above I
believe that you are applying the e2e argument in a too general way.
The topic of end-to-end versus link-layer reliability has been one of the
largely debated topics of the PILC working group. The current group
concensus is that strong LL reliability is a really good thing *if* it is
only applied to reliable e2e flows, e.g. all TCP-based flows, and does not
interfere with the other possibly delay-sensitive flows going across the
Note, that this is *not* promoting large queues. No, queues should be
appropriately small and active queue management is a good thing.
Note also, that this is *not* saying that hop-by-hop reliability could
replace e2e reliablity. Clearly, it can't (e2e argument).
Yes, "more efficient" is one of the reasons to argue in favor of LL
reliability as a complement to TCP. The error characteristics of some
wireless links are such that very often only tiny fractions of a large IP
packet is broken (e.g., only a single LL frame with a 24 bytes payload).
Having the LL receiver throw away the entire IP packet including the 98
percent of it that made it across the link fine, and rely on TCP to
retransmit is wasteful. It wastes possibly expensive spectrum that the user
will need to pay for. It also wastes transmission power (battery lifetime).
At the same time it reduces e2e throughput and increases traffic that needs
to travel e2e.
A reason that argues in favor of *strong* LL reliability as a complement to
TCP are link outages that may often occur when wireless. Link outages are
periods of time, say between 1 and 60 seconds, where there is no physical
connectivity because the mobile transmitter is going through a tunnel or is
temporarily in an elevator. The problem of *weak* LL reliability in this
case would be that eventually all of a TCP flow's packets (acks and data)
would be lost (discarded by that LL), while the TCP sender would back off
its retransmission timer to possibly very large values. That would result
in very poor e2e performance.
Please, check out the corresponding PILC draft
especially the sections "TCP vs Link Layer Retransmission" and "Recovery
from Subnetwork Outages". That draft is scheduled to go into last call to
become an RFC in BCP status. It would be great if you could review it and
comment to pilc at grc.nasa.gov.
I gave a talk on that topic at the IETF last December. The talk is titled
"Can Wireless Preserve the E2E Argument?" and is available off the PILC
homepage at http://pilc.grc.nasa.gov/ (look for "Flow Adaptive ARQ Proposal").
More information about the end2end-interest