[e2e] Routers accessing TCP header

Ibrahim Matta matta at cs.bu.edu
Wed Feb 23 08:37:59 PST 2005

I admit not reading this paper (yet:) But I am wondering what kind of
recovery strategy is used (e.g. TCP not backing off completely, or...)
once you know the "exact" reason of loss (through your oracle). I think
how much gain will depend not only on the "binary" classification of
loss type (e.g. buffer overflow or transmission error) but also on the
action TCP flows take, how synchronized they are, etc. Actually, a finer
grained error classification (e.g. short-term vs. long-term error
conditions etc.) along with a finer grained recovery response maybe


-----Original Message-----
From: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] On Behalf Of Rajesh
Sent: Tuesday, February 22, 2005 2:55 PM
To: Craig Partridge
Cc: end2end-interest at postel.org; Arjuna Sathiaseelan
Subject: Re: [e2e] Routers accessing TCP header

> >Dear Jon,
> >  Thanks for your appropriate reply. I am basically working on a 
> >mechanism called the Explicit Packet Drop Notification (EPDN).
> While the mechanism is slightly different, this sounds like Explicit 
> Transport Error Notification (ETEN) done again.  See:
>     Rajesh Krishnan, James P.G. Sterbenz, Wesley M. Eddy, Craig
>     and Mark Allman, "Explicit transport error notification (ETEN) for

>     error-prone wireless and satellite networks," Computer Networks,
>     46(3), October 2004, pp. 343-362.
> I'll note that my co-authors and I continue to debate exactly how much

> benefit such a service provides.  My reaction, from the "Oracle ETEN" 
> simulations in the paper (where we report the maximum improvement 
> possible if you know perfectly and immediately which packets are lost)

> is that the gains are not enough to merit implementing the service. 
> Your mileage may vary!
> Craig

The Oracle ETEN plots do show that there are benefits from notifications

at _high_ error rates.  The debate is about:

  - are the high error rates at which we see appreciable gains from 
    notifications just too disruptive to be usable in practice (e.g. 
    even for neighbor discovery and routing protocols to function 
    properly, let alone run TCP)

  - are the environments that can benefit from notifications just too 
    special to merit retrofitting a general-purpose transport protocol
    (and would it not be more efficient to handle these special
     locally rather than end-to-end)

Notifications on a per-packet basis consume additional network resources

and are potentially a security risk as well; schemes that can work with 
cumulative notifications are desirable.  Unfortunately the performance 
of the cumulative scheme we developed was nowhere near as good as the 
Oracle ETEN results.  This is not to say that better schemes cannot be 
devised (and I believe they can), but a moot point if you agree with 
Craig that there is not much benefit to be realized to begin with even 
with perfect instantaneous knowledge of losses.

Best Regards,

More information about the end2end-interest mailing list