1. By Arjuna Sathiaseelan Tomasz Radzik Department of Computer Science King’s College London EPDN: Explicit Packet Drop Notification and its uses

2. Motivation Reordering or Corruption of packets leads to overestimation of the congestion of the network. Decreases the TCP performance of a network Imperative to propose a mechanism that allows the TCP sender to know the exact cause of the out of order data

3. Problem of Packet Reordering Packet reordering is common : due to parallelism in networks. Parallelism reduces cost of equipments and trunks. Types of Parallelism: Local parallelism : Multiple paths within a device. Multi-path routing. Effects of Parallelism: Decreases the TCP performance of the network.

4. Detecting packet loss Retransmission Timer Fast Retransmit

5. Implications of Reordering Unnecessary retransmission of data segments means that some of the bandwidth is wasted. Unnecessary reduction of the congestion window. TCP ensures that the receiving application receives data in order. Burden on the TCP receiver since the receiver must buffer the out- of-order data until the missing data arrive to fill the gaps.

6. Impact of Reordering

7. Related Work [Floyd, Mahdavi, Mathis, Podolsky; 2000]: DSACK option allows the TCP receiver to report to the sender when duplicate segments arrive at the receiver. Using this information, the sender can determine when a retransmission is spurious. If spurious, the cwnd can be restored to the previous value. RR-TCP [Zhang, Karp, Floyd, Peterson; 2003]: RR-TCP: mechanisms to detect and recover from false retransmits using the DSACK information. They propose several algorithms for proactively avoiding false retransmits by adaptively varying DUPTHRESH.

8. EPDN: Explicit Packet Drop Notification Each gateway has a hashtable storing entries: i is the flow id (also the key used to index the hashtable). max:PNO is the maximum sequence number of the packet dropped in the gateway. min:PNO is the minimum sequence number of the packet dropped in the gateway.

9. Packet Drop Hash Table Flow Id: Min: Max: P1 Received Packets P1 P2 Hash Table Flow Id: 1 Min: P2 Max: P2 P3 Hash Table Flow Id: 1 Min: P2 Max: P3 P4 Hash Table Flow Id: Min: Max: P4 3,2 Received Packets P1 P4 Droplist: Reorderedlist: Droplist: 2 3

10. Packet Reorder Hash Table Flow Id: Min: Max: P1 Received Packets P1 P2P3 Droplist: Reorderedlist:Reorderedlist: P2 Received Packets P1 P3

11. RN-TCP: Reorder Notifying TCP Receiver uses the following information to identify whether a packet has been dropped or reordered. Packet Notation: P P:n - Sequence number of the current received packet P:max - Maximum dropped entry P:min - Minimum dropped entry Q:n - Last received packet in the receiver buffer queue

12. RN-TCP: Reorder Notifying TCP (contd.) Receiver maintains two lists: - Reorder List - Drop List Drop is notified by not setting ‘drop-negative’ bit in the ACK. Reorder is notified by setting ‘drop-negative’ bit in the ACK.

13. Storage and Computational Costs The IP options field has 40 bytes. We use 4 bytes for each minimum and maximum dropped entries to be inserted into the option field of the IP segment. We use one bit from the reserved bits in TCP to denote the ‘drop-negative' bit. Our monitoring process records only flows whose packets have been dropped. When the dropped information is inserted into the corresponding packet that leaves the gateway successfully, the entry is deleted. Rough estimate: 500KB SRAM would be sufficient for storing infoirmation about dropped packets ?

14. Storage and Computational Costs(contd..) For each packet, the computational cost in each gateway is constant, assuming a constant time access/update of the hashtable. Computational costs at the receiver are as follows: - Insertion O(n) where n is the number of packets the receiver has assumed to be dropped or reordered. -Deletion and comparison costs O(m) where m is the length of the list. Computational cost O(log n) and O(log m) respectively if we use balanced trees.

15. Simulation Details Used Network Simulator ns-2. Segment size : 1500 bytes. Conducted experiments for Drop-tail. Queue size used : 65 segments. Used FTP traffic flows.

16. Throughput – Packet Delays (Delays: Normally distributed with mean = 25ms, std.dev = 8ms)

17. Throughput – Multipath Routing (Delays: Modal Distribution)

18. Link Utilization (30% Packets Delayed)

19. Throughput: Delays and Drops (5% Packets Delayed)

20. TCP-R : Robust TCP RN-TCP: proposed for terrestrial networks. Terrestrial networks: - the out of order packets are caused mainly due to losses related to congestion and reordering of packets. - Losses due to corruption is negligible. Satellite links have high RTTs, typically on the order of several hundred milliseconds. Losses mainly due to corruption than congestion. If a packet had been actually dropped due to corruption, having an increased value of dupthresh requires a RTO to detect the packet loss. Imperative to propose a mechanism that improves the performance when packets get corrupted, reordered and dropped for networks with large RTT.

21. TCP-R : Robust TCP TCP-R uses EPDN. The TCP-R receiver informs the TCP-R sender about its assumption. If the packets had been dropped in the network, the lost packets are retransmitted after waiting for 3 DUPACKS (fast retransmit) and reduces the congestion window by half (fast recovery). If the packets are assumed to be reordered or corrupted in the network, -TCP-R sender retransmits the packet after receiving three DUPACKS -Enters our modified fast recovery mechanism where the procedure of reducing the slow start threshold (ssthresh) and the congestion window (cwnd) are bypassed.

22. Simulations Segment size : 1000 bytes Queue size used : 100 segments. Used FTP traffic flows.

23. Throughput – Packet Delays (Delays: Normally distributed with mean = 200ms, std.dev = 80ms)

24. Throughput: Delays and Corruption (5% Packets Delayed) AND Timeout Avoidance

25. Throughput – Delays and Drops (3% Packets Delayed)

26. Future Work Scalability of EPDN in wired networks – is it possible just to use EPDN in hot spots where packets get dropped? In case the routing changes and if the dropped information cannot be propagated to the receiver - send the dropped information in an ICMP message to the sender ? Use the RED packet drop history for EPDN? Verify the size requirements needed for EPDN?