1. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 1 Explicit Transport Error Notification (ETEN) R. Krishnan, M. Allman, C. Partridge, J Sterbenz: BBN W. Ivancic: NASA Glenn

2. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 2 ETEN If one could determine that a TCP packet was lost due to an errored condition rather than due to congestion then one would not initiate congestion control for packet loss due to errors thereby improving the overall bandwidth utilization. –The ability to identify errors at the network and/or transport layer is extremely difficult. –Once an error condition has been identified, what one does with this is also questionable. By being in error we have already determined the information to be unreliable. –Potential security problems – particularly denial of service.

3. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 3 ECN and ETEN, What’s the Difference? ECN = Explicate Congestion Notification –Congestion easily identified in routers –Notification of onset of congestion Tell source to slow down –Still experimental ETEN = Explicit Transport Error Notification –Notification that packet was lost due to corruption –Currently a research topic –ETEN needs to be assessed within congested networks Current NASA related work has no congestion

4. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 4 Oracle ETEN (Oracle) Assumes perfect knowledge of errors vs congestion –SCPS-TP rate-based approach

5. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 5 Backward ETEN (BETEN) Router send corruption message back to source (similar to Backward ECN)

6. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 6 Forward ETEN (FETEN) Router sends corruption message to sink which returns message to source (similar to Forward ECN)

7. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 7 Receiver-based ETEN (RETEN) It is possible for the receiver to infer corruption losses using sequence numbers and/or timestamps and explicitly notify the sender.

8. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 8 Cumulative ETEN (CETEN) Consider mechanisms that can work with cumulative error rates (for example, error rates that are averaged over an interval of time and across various flows). –Absolute bit error rate, byte error rate, or packet error rate observed within a moving window in time –The error rate from the previous case quantized into a small number of steps (for example, high, medium, and low) –A special instance of the previous case is a binary feedback scheme [13] that is analogous to ECN [26], which can indicate that the bit/byte/packet error rate exceeds a threshold –A relative error rate which simply indicates that the quantized error rate increases or decreases from the previous value –An estimate of the probability that a packet survives corruption

9. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 9 Cumulative ETEN (CETEN) CETEN can be delivered to the sender via forward of backward signaling, analogous to a FETEN- based or a BETEN-based strategy. CETEN information can be collected on a per-hop basis or aggregated over the end-to-end path.

10. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 10 Tests Baseline – No cross traffic over a single-hop topology Multi-hop topology with no cross-traffic Multi-hop topology with non-TCP cross traffic Multi-hop topology with competing TCP flows Comparing ETEN to TCP Westwood with no congestion Comparing ETEN to TCP Westwood under congestion Cumulative ETEN performance with UDP cross traffic Cumulative ETEN performance with TCP cross traffic

11. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 11 Experiment Parameter Ranges Forward CETEN and TCP Westwood were also simulated.

12. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 12 TCP with ETEN over an uncongested long thin network Theoretical Improvement For good links Everything is acceptable

13. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 13 SACK TCP with ETEN over a congested 3-hop LTN of one way path delay 960 ms with UDP cross-traffic Sufficient Bandwidth is available To handle multiple flows (limited congestion) Insufficient Bandwidth is available To handle multiple flows (moderate congestion)

14. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 14 BETEN-SACK vs TCP Westwood ETEN performs superior To TCP Westwood at High BER ETEN performs superior To TCP Westwood at High BER

15. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 15 CETEN Very Little Congestion Congested Link.

16. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 16 BETEN-SACK vs TCP Westwood (8 flows) If congestion dominates, neither ETEN nor TCP Westwood help.

17. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 17 Conclusions Results indicate that ETEN mechanisms can improve the performance of TCP Reno and TCP SACK in uncongested networks across a wide range of path capacities and delays. –An order of magnitude improvement in goodput was observed in some cases in the BER range of 10 -5 to 10 -7 With competing TCP flows, a given TCP flow using ETEN performs better at high error rates when compared to the the same flow not using ETEN. ETEN mechanisms slightly outperform TCP Westwood at very high error rates. At lower error rates, Westwood performs better in the absence of congestion.

18. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 18 Conclusions Key routers (but probably not all routers) must implement ETEN for it to be viable. Requires layer 2 devices to communicate with layer 3 Numerous security issues –Use of encryption can prevent deep header inspection. –ETEN techniques (such as BETEN, for example) that require additional messages are especially vulnerable to distributed denial of service (DDOS) attacks –Spoofed ETEN messages can cause the TCP sender to be aggressive, thereby causing congestion

19. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 19 Conclusions Cumulative ETEN techniques are more attractive to implementation than per packet mechanisms. –The particular mechanism we evaluated did not realize the potential gains of per-packet techniques

20. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 20 Recommendations Alternative cumulative ETEN mechanisms should be investigated to see if we can obtain performance the more closely resembles theoretical per packet Backward ETEN.

21. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 21 Recommendations (If we can identify a good Cumulative ETEN Implementation) The fairness of Cumulative ETEN to other TCP flows be studied in detail The effectiveness of ETEN be evaluated under other error models such as bursts and channel fades Mechanisms need to be evaluated using real network topologies and traffic traces including other workloads, for example, HTTP transactions A TCP/ETEN prototype including the required IP router support should be implemented and tested for performance and analyzed for security vulnerabilities.

22. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 22 Recommendations (Assuming congested end-to-end paths) It the majority of end-to-end links are congested then: –ETEN does not provide a big enough gain for the complexity; therefore, –Terminate Investigation

23. Glenn Research Center Satellite Networks & Architectures Branch Communications Technology Division ESTO Annual Review July 1, 2001 – January 30, 20022/2002 23 Status BBN Task complete and final electronic version of the final report is available (Formal NASA report is in progress) –www.ir.bbn.com/projects/pace/eten NS-2 implementation –Oracle ETEN and Backward ETEN were implemented –We have extended the ns-2 simulator to support ETEN simulations Added a Trace/ETEN class to support tracing of packets dropped by the error module. Modified the Agent/TCP/FullTcp and Agent/TCP/FullTcp/Sack to include two new commands: eten-retransmit and fast-retransmit. –These TCP agents can now be commanded to retransmit a given sequence number regardless of TCP’s current state.