1 / 56

Reliable Transport Protocols Should Forbid Reneging

Reliable Transport Protocols Should Forbid Reneging. Nasif Ekiz Paul D. Amer, Professor Preethi Natarajan Ertugrul Yilmaz Jon Leighton Abu Rahman. sponsored by. U.S. Army Research Lab. Outline. transport layer selective acknowledgments (SACKs) what are SACKs? how are SACKs renegable?

chava
Download Presentation

Reliable Transport Protocols Should Forbid Reneging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reliable Transport Protocols Should Forbid Reneging Nasif Ekiz Paul D. Amer, Professor Preethi Natarajan Ertugrul Yilmaz Jon Leighton Abu Rahman sponsored by U.S. Army Research Lab

  2. Outline • transport layer selective acknowledgments (SACKs) • what are SACKs? • how are SACKs renegable? • what is the gain in making selective acks non-renegable? • what is the penalty in making selective acks non-renegable? • Conclusion: • selective acks for reliable transport protocols (e.g., TCP, SCTP) should be non-renegable

  3. Transport layer receive buffer receiving application datasender receive buffer 3 4 5 7 9 11 12 13 ordered data (ACKed) Internet out-of-order data (SACKed) available space

  4. Types of acknowledgments • For ordered data - cumulativeACKn • bytes [ ... to n-1 ](TCP) [RFC 793] • segments [ ... to n ] (SCTP) [RFC 2960] • For out-of-order data - selectiveACK (SACK) m-n • bytes [ m to n-1 ](TCP)[RFC 2018] • segments [ m to n ](SCTP) [RFC 2960] • prevent unnecessary retransmissions during loss recovery • improve throughput when multiple losses in same window

  5. Types of ACKs receive buffer data receiver data sender 1 ACK 1 1 2 2 ACK 2 3 4 ACK 2, SACK 4-4 4 5 ACK 2, SACK 4-5 4 5 6 ACK 2, SACK 4-6 4 5 6 3 ACK 6 3 4 5 6

  6. What is reneging? • [RFC 2018]: “The SACK option is advisory, in that, while it notifies the data sender that the data receiver has received the indicated segments, the data receiver is permitted to later discard data which have been reported in a SACK option.” • discarding SACKed data before delivery to the receiver application (or socket) is “reneging” • TCP and SCTP allow reneging - data sender retains copies of all SACKed data until ACKed

  7. Reneging example receiver buffer data receiver data sender 1 ACK 1 1 2 2 ACK 2 3 4 ACK 2, SACK 4-4 4 5 ACK 2, SACK 4-5 4 5 6 ACK 2, SACK 4-6 4 5 6 OS needs memory and reneges 3 3 ACK 3 7 ACK 3, SACK 7-7 7

  8. Summary of reneging • Reneging : data receiver SACKs data, and later discards it (i.e., SACK information is “advisory”, not a delivery guarantee) • Reneging is discouraged but permitted • Data sender keeps data in a send buffer until cumulatively ACKed (i.e., cum ack is a guarantee) Special Case for SCTP – out-of-order data already delivered to the application is non-renegable by definition

  9. Special case for SCTP: unordered data receive buffer data sender data receiver 1 1 ACK 1 2 3 ACK 1, SACK 3-3 3 4 unordered ACK 1, SACK 3-4 4 3 5 ACK 1, SACK 3-5 5 3 6 unordered ? ?

  10. Special case for SCTP: unordered data receive buffer data sender data receiver 1 1 ACK 1 2 3 ACK 1, SACK 3-3 3 4 unordered ACK 1, SACK 3-4 4 3 5 ACK 1, SACK 3-5 5 3 6 unordered ACK 1, SACK 3-6 5 6 3 5 3 2 5 2 3 ACK 6 7 ACK 7 7

  11. We argue that tolerating reneging is wrong Part I: What is the gain in forbidding selective acks? • Suppose SACKs were a guarantee of delivery, not advisory • All SACKs are non-renegable (NR-SACKs) • Data receiver takes responsibility for all selectively acked data • Data sender can remove NR-SACKed data from send buffer • always improved send buffer utilization (TCP and SCTP) “Non-renegable selective acks for SCTP” Int'l Conf on Network Protocols (ICNP), Orlando, 10/08 • sometimes improved throughput (SCTP) “Throughput analysis of Non-Renegable Selective Acks for SCTP” Computer Communications, 33(16), 10/10

  12. Send buffer utilization (SACK) send buffer data sender data receiver receive buffer 100% 1 1 1 ACK 1 100% 1 2 2 100% 1 2 3 3 ACK 1, SACK 3-3 3 100% 4 1 2 3 4 ACK 1, SACK 3-4 4 100% 5 2 3 4 5 ACK 1, SACK 3-5 5 75% 2 3 4 5 send buffer blocking 50% 2 3 4 5 25% 2 3 4 5 25% 2 3 4 5 2 ACK 5 2 100% 6 6

  13. Send buffer utilization (NR-SACK) send buffer data sender data receiver receiver buffer 100% 1 1 1 ACK 1 100% 1 2 2 100% 1 2 3 3 ACK 1, NR-SACK 3-3 3 100% 4 1 2 3 4 ACK 1, NR-SACK 3-4 4 100% 5 2 3 4 5 ACK 1, NR-SACK 3-5 5 100% 2 4 5 6 6 ACK 1, NR-SACK 3-6 6 no send buffer blocking 100% 2 5 6 7 7 ACK 1, NR-SACK 3-7 7 100% 2 5 6 7 2 ACK 7 2 100% 2 6 7 8 8 8 ACK 8 100% 2 7 8 9 9 9 ACK 9 100% 8 2 8 9 9 10 10 11 10 10 ACK 10 100% 11

  14. NR-SACK ns-2 simulation

  15. NR-SACK FreeBSD implementation

  16. Send buffer utilization (ns-2) NR-SACK As traffic load increases, NR-SACKs better utilize send buffer ∞ SACK SACK 64K SACK 32K Send Buffer Utilization

  17. Send buffer utilization (FreeBSD) Send Buffer Utilization ∞

  18. Throughput gains (ns-2) (only for SCTP not TCP) NR-SACKs never do worse than SACKs

  19. We argue that tolerating reneging is wrong Part II: What is penalty in forbidding selective acks? Let’s assume transport protocols are designed to forbid data reneging • Changing TCP or SCTP to non-reneging protocol is easy: • SACK semantics changed from advisory to permanent • if data receiver needs to renege, data receiver MUST RESET the connection ( this is the penalty)

  20. How big is the penalty? answer: depends on how often reneging happens • Data reneging has never been studied • Does data reneging happen or not? • If reneging happens, how often? Hypothesis: “data reneging rarely if ever occurs in practice” • Suppose reneging occurs 1 in 100,000 TCP (or SCTP) flows • Case A (current practice): reneging allowed • 99,999 non-reneging connections underutilize send buffer (and for SCTP may achieve lower throughput) • 1 reneging connection continues (maybe...) • Case B (proposed change): reneging forbidden • 99,999 connections have equal or better send buffer utilization (and for SCTP potential greater throughput) • 1 reneging connection is RESET

  21. Detecting TCP reneging at a router State of receive buffer receive buffer Router Data Sender Data Receiver 1 1 2 3 3 4 ACK 1, SACK 3-4 4 3 5 ACK 1, SACK 3-4 4 5 3 6 ACK 1, SACK 3-6 4 5 6 3 ACK 1, SACK 3-6 OS reneges 2 2 7 ACK 2, SACK 7-7 7 ACK 2, SACK 3-6 ? reneging detected

  22. Model to detect reneging Current New SACK 12-17 SACK 12-15 SACK 12-13 SACK 12-17 SACK 22-25 SACK 12-17 SACK 15-20 SACK 12-17 Current state (C) and new SACK (N) are compared 4 possibilities:

  23. Model to detect reneging Current state (C) New SACK (N) Reneging (R)

  24. Model to detect reneging • TCP flows • with SACKs • reneging? CAIDA* trace TCP flow filter Reneg Detect • yes • or • no • .pcap • tshark • ~4600 lines of C code • editcap • ACK reordering check • mergecap • *Cooperative Association for Internet Data Analysis

  25. Model verification • “Misbehaviors in TCP SACK Generation” (Ekiz, Rahman, Amer) • (ACM SIGCOMM Computer Communication Review, April 2011) • RenegDetect was tested with synthetic TCP flows • created reneging flows with text2pcap • all reneging flows were identified correctly • RenegDetect was tested with real TCP flows from CAIDA Internet traces • at first, reneging seemed to occur frequently • on closer inspection, we found that many SACK implementations are incorrect !

  26. Incorrect SACK implementations

  27. Experiment design – how to “prove” reneging does not happen? Event A: TCP flow reneges Hypothesis: We want to design an experiment which rejects H0 with 95% confidence to conclude Our experiment will observe n TCP flows hoping to NOT find even a single instance of reneging Using MAPLE, n ≥ 299,572

  28. Questions ?(thank you)

  29. TCP Send buffer utilization (SACK) send buffer data sender data receiver receiver buffer 100% 1 1 1 ACK 1 100% 1 2 2 100% 1 2 3 3 ACK 1, SACK 3-3 3 100% 4 1 2 3 4 ACK 1, SACK 3-4 4 3 100% 5 2 3 4 5 ACK 1, SACK 3-5 4 4 4 4 5 5 5 5 3 3 3 3 send buffer blocking 75% 2 3 4 5 50% 2 3 4 5 25% 2 2 3 4 5 ACK 5 4 5 2 3 6 100% 6 6 ACK 6

  30. TCP Send buffer utilization (NR-SACK) send buffer data sender data receiver receiver buffer 100% 1 1 1 ACK 1 100% 1 2 2 100% 1 2 3 3 ACK 1, NR-SACK 3-3 3 100% 4 1 2 3 4 ACK 1, NR-SACK 3-4 3 4 100% 5 2 3 4 5 ACK 1, NR-SACK 3-5 3 4 5 100% 2 4 5 6 6 NO send buffer blocking 3 4 5 6 ACK 1, NR-SACK 3-6 100% 7 2 5 6 7 3 4 5 6 7 ACK 1, NR-SACK 3-7 100% 2 2 5 6 7 ACK 7 2 3 4 5 6 7 100% 2 6 7 8 8 8 9 10 ACK 8 100% 2 7 8 9 9 ACK 9 100% 2 8 9 10 10 ACK 10 100% 8 9 10 11 11

  31. Data reneging in OSes • Reneging in Linux (version 2.6.28.7) • tcp_prune_ofo_queue() deletes out-of-order data • Reneging in FreeBSD, Mac OS • net.inet.tcp.do_tcpdrainsysctl turns reneging on/off • tcp_drain() deletes out-of-order data

  32. Data reneging in Linux

  33. 3. Inferring the state of receive buffer

  34. 3. Inferring the state of receive buffer

  35. NR-SACK Negotiation INIT – NR-SACKs Supported INIT-ACK – NR-SACKs Supported SCTP Association Startup COOKIE-ECHO COOKIE-ACK DATA SCTP Data Transfer NR-SACKs(cum-ack,gap-ack,nr-gap-ack,dup-TSN)

  36. NR-SACK Chunk Chunk Flags Type = 0x10 Chunk Length ACK Cumulative TSN Ack Advertised Receiver Window Credit Number of Gap Ack Blocks = N Number of NR-Gap-Ack Blocks = M Reserved Number of Duplicate TSNs = X SACK Gap Ack Block #1 End Gap Ack Block #1 Start Gap Ack Block #N Start Gap Ack Block #N End NR-SACK NR-Gap Ack Block #1 End NR-Gap Ack Block #1 Start NR-Gap Ack Block #M Start NR-Gap Ack Block #M End D-SACK Duplicate TSN 1 Duplicate TSN X

  37. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID : Stream Identifier SSN : Stream Sequence Number

  38. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID : Stream Identifier SSN : Stream Sequence Number

  39. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID : Stream Identifier SSN : Stream Sequence Number

  40. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 SID : Stream Identifier SSN : Stream Sequence Number

  41. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID : Stream Identifier SSN : Stream Sequence Number

  42. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID: 1 SSN: 3 5 ? ? SID : Stream Identifier SSN : Stream Sequence Number

  43. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID: 1 SSN: 3 5 ACK 1, SACK 3-5 5 4 SID : Stream Identifier SSN : Stream Sequence Number

  44. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID: 1 SSN: 3 5 ACK 1, SACK 3-5 5 4 6 SID: 2 SSN: 3 ACK 1, SACK 3-6 6 4 6 4 SID : Stream Identifier SSN : Stream Sequence Number

  45. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID: 1 SSN: 3 5 ACK 1, SACK 3-5 5 4 6 SID: 2 SSN: 3 ACK 1, SACK 3-6 6 4 6 4 SID: 2 SSN: 1 2 6 2 4 ACK 6 SID : Stream Identifier SSN : Stream Sequence Number

  46. When is data non-renegable? case 2: multistreaming receiver buffer data sender data receiver SID: 1 SSN: 1 1 1 ACK 1 SID: 2 SSN: 1 2 SID: 1 SSN: 2 3 ACK 1, SACK 3-3 3 4 SID: 2 SSN: 2 ACK 1, SACK 3-4 4 SID: 1 SSN: 3 5 ACK 1, SACK 3-5 5 4 6 SID: 2 SSN: 3 ACK 1, SACK 3-6 6 4 6 4 SID: 2 SSN: 1 2 6 2 4 ACK 6 7 SID: 1 SSN: 4 ACK 7 7 SID : Stream Identifier SSN : Stream Sequence Number

  47. When is data non-renegable? Case 3: OS guarantee Receiver Buffer Data Sender Data Receiver

  48. When is data non-renegable? Case 3: OS guarantee Receiver Buffer Data Sender Data Receiver 1 1 ACK 1

  49. When is data non-renegable? Case 3: OS guarantee Receiver Buffer Data Sender Data Receiver 1 1 ACK 1 2

  50. When is data non-renegable? Case 3: OS guarantee Receiver Buffer Data Sender Data Receiver 1 1 ACK 1 2 3 ACK 1, SACK 3-3 3

More Related