ETEN

1. Explicit Transport Error Notification(ETEN)R. Krishnan, M. Allman, C. Partridge, J Sterbenz: BBN W. Ivancic: NASA Glenn

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. 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. Oracle ETEN (Oracle) • Assumes perfect knowledge of errors vs congestion • SCPS-TP rate-based approach

5. Backward ETEN (BETEN) • Router send corruption message back to source (similar to Backward ECN)

6. Forward ETEN (FETEN) • Router sends corruption message to sink which returns message to source (similar to Forward ECN)

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. 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. 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. 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. Experiment Parameter Ranges Forward CETEN and TCP Westwood were also simulated.

12. TCP with ETEN over an uncongested long thin network For good links Everything is acceptable Theoretical Improvement

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. BETEN-SACK vs TCP Westwood ETEN performs superior To TCP Westwood at High BER ETEN performs superior To TCP Westwood at High BER

15. CETEN Very Little Congestion Congested Link.

16. BETEN-SACK vs TCP Westwood (8 flows) If congestion dominates, neither ETEN nor TCP Westwood help.

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. 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. 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. 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. 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. 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 It is to early to make this call.

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.