[e2e] Routers accessing TCP header

[Rajesh Krishnan]

Ibrahim,

When the oracle notifies the TCP sender of a segment lost due to corruption, 
we have the sender retransmit the segment immediately without adjusting the 
congestion window.  (Drops due to congestion are discovered and handled using 
the normal TCP mechanisms.)  In our study, the sender did not have explicit
information about other flows.

In addition to the Oracle case, we tried a couple of cumulative notification 
strategies that require (intermediate routers attached to error-prone links 
to update) a header field that accumulates a corruption survivability metric 
along the path.  Upon a loss event, based on the metric the sender can either 

  - probabilistically decide the loss is due to corruption and retransmit
    without reducing the congestion window 
  
  - deterministically compute a multiplicative decrease factor that depends 
    on the corruption survivability metric rahter than the tradition value
    TCP uses (one half)

Best Regards,
Rajesh

> 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
> needed?
> 
> Best,
> Ibrahim
> 
> 
> -----Original Message-----
> From: end2end-interest-bounces at postel.org
> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Rajesh
> Krishnan
> 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
> Partridge
> >     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
> anomalies 
>      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,
> Rajesh
>