Subject: Explicit Transport Error Notification

From: William Ivancic <[email-masked]>
Date: Tue, 02 Apr 2002 15:15:53 -0500

BBN has recently completed a NASA funded research task on Explicit 
Transport Error Notification (ETEN).
The report and ns implementation are available at:
http://wizards.ir.bbn.com/projects/pace/eten/

NASA funded this work because NASA would like to use COTS protocols such as 
TCP.  As many of NASA's links are error-prone, it would be advantageous if 
TCP could determine the difference between a packet loss due to errors and 
a packet loss due to congestion.  This report is a first pass at 
determining what the possible improvements may be if TCP reacted to errors 
differently than to congestion.  In addition, issues related to practical 
deployment are discussed.

In this study  two types of ETEN mechanisms are proposed: (i) per-packet 
mechanisms that notify endpoints
of each detected corruption; and (ii) cumulative mechanisms that notify 
endpoints of aggregate corruption
statistics.  The proposed mechanisms have been implemented in the ns-2 
simulator. The simulation
results are presented on performance gains achievable for TCP Reno and TCP 
SACK, using ETEN mechanisms over
a wide range of bit error rates and traffic conditions. In addition, TCP 
Reno and TCP SACK enhanced with
ETEN mechanisms are compared against TCP Westwood, which uses a bandwidth 
estimation strategy in place of the traditional
AIMD congestion avoidance algorithm. Two issues related to the practical 
deployment
of ETEN mechanisms are discussed: corruption detection mechanisms (and 
their co-operation with ETEN-based recovery
in the transport layer) and security aspects.

This work represents a very good start to investigations into ETEN.  I 
would appreciate any feedback related to the work.  In particular, thoughts 
on whether or not the potential performance improvements would justify 
deployment.  If deployment is justified, which areas of research may be 
best to address?

Thanks for your help.

Will Ivancic

=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 2 Apr 2002 14:12:33 -0800

> would appreciate any feedback related to the work.  In particular, 
> thoughts on whether or not the potential performance improvements would 
> justify deployment.  If deployment is justified, which areas of research 
> may be best to address?   

Explicit error notification is just one way to distinguish between losses due to transmission errors and losses due to congestion. An alternative way is to use explicit congestion notification, and assume that packet losses are due to other factors -- e.g., only shrink the window on ECN, and expend it on the ACK. There are obvious deployment issues, but these could be solved if NASA is operating in any kind of controlled set-up. In any case, the ECN only option could be simulated in NS...

-- Christian Huitema

---

From: James Sterbenz <[email-masked]>
Date: Tue, 02 Apr 2002 18:03:36 -0500

At 02:12 PM 4/2/2002 -0800, Christian Huitema wrote:
 >> Will Ivancic wrote:
>Explicit error notification is just one way to distinguish between losses 
>due to transmission errors and losses due to congestion. An alternative 
>way is to use explicit congestion notification, and assume that packet 
>losses are due to other factors -- e.g., only shrink the window on ECN, 
>and expend it on the ACK. There are obvious deployment issues, but these 
>could be solved if NASA is operating in any kind of controlled set-up. In 
>any case, the ECN only option could be simulated in NS...

This is discussed in the report, but it is not quite so simple.  That is, a 
given packet can
cause congestion, and then also suffer a channel error.  So it is not true 
that you can
directly compute corruption from ECN or congestion from ETEN in the case of 
lossy congested
networks.

Cheers,
James

---------------------------------------------------------------------
James P.G. Sterbenz                                      [email-masked]
Senior Network Scientist                                 [email-masked]
Research Group Manager                                +1 617 873 5063
Internetwork Research, BBN Technologies