[e2e] E2E vs. LL Reliability [e2e principle..where??....]

[Reiner Ludwig]

Hi David,

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 
same link.

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 
http://search.ietf.org/internet-drafts/draft-ietf-pilc-link-design-05.txt, 
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").

///Reiner