[e2e] Routers accessing TCP header

[Arjuna Sathiaseelan]

Dear Craig and Rajesh,
  I was going through your ETEN mechanism and some questions arose.
Doesnt Explicit Loss Notification solve the problem of distinguishing
corruption and congestion effectively ? So is there any need for
creating a new mechanism (this includes my EPDN and your ETEN) to
detect the cause of loss? Does ELN have any shortfalls? I would be
very much obliged if you could shed some light on this .

Regds,
Arjuna


On Wed, 23 Feb 2005 16:46:17 -0500 (EST), Rajesh Krishnan <krash at bbn.com> wrote:
> 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
> >
> 
>