Presentation is loading. Please wait.

Presentation is loading. Please wait.

Spurious Retransmission Detection (SRD) with the TCP Echo Options draft-zimmermann-tcpm-spurious-rxmit Richard Scheffenegger <rs@netapp.com> Alexander.

Similar presentations


Presentation on theme: "Spurious Retransmission Detection (SRD) with the TCP Echo Options draft-zimmermann-tcpm-spurious-rxmit Richard Scheffenegger <rs@netapp.com> Alexander."— Presentation transcript:

1 Spurious Retransmission Detection (SRD) with the TCP Echo Options draft-zimmermann-tcpm-spurious-rxmit Richard Scheffenegger Alexander Zimmermann

2 Problem Statement Eifel detection
Uses TCP Timestamp options [RFC 7323] to detect spurious retransmissions Limited applicability due to TSecr semantics, and TSval granularity No detection of reordering during loss recovery Idea: Make every segment – including all retransmissions – uniquely identifiable (to the sender) Allows all functionality of Eifel, even during corner cases Enables new capabilities (lost retransmission detection)

3 Spurious Retransmission Detection (SRD)
Mechanism Use TCP Echo Option to send a (small) counter in each segment to keep MSS equal for retransmissions Increase counter when sending a new round of retransmissions e.g. (re-)entering loss recovery Check counter in received ACK Equal to current value  valid retransmission Else spurious retransmissions Property Semantics of TCP Echo allows to determine the exact ordering of transmissions, even in case of reordering

4 Example (Semantics) RFC7323 TSecr reflects TS of last in-sequence segment Source Destination Source Destination S1, E1 S2, E2 S3, E3 A2, E1 A2, E3 A4, E2 S1, TS1 S3, TS3 S2, TS2 A2, TS1 S4, TS4 S4, E4 A2, TS1 A4, TS2 A5, TS4 A5, E4

5 Example (Eifel vs. SRD) Granularity of TS often too coarse S1, TS1
Source Destination Source Destination S1, TS1 S2, TS1 S3, TS1 A2, TS1 A5, TS1 S4, TS1 S1, E1 S2, E1 S3, E1 A2, E1 A5, E1 S4, E1 S2, E2 A5, E2

6 Example (Eifel vs. SRD) Eifel only works on first retransmitted segment Source Destination Source Destination S1, TS1 S1, E1 A2, TS1 A2, E1 S4, TS2 S4, E1 S5, TS2 S5, E1 S2, TS1 S3, TS2 S2, E1 S3, E1 S6, TS2 S6, E1 A2, TS1 A2, E1 A2, TS1 A2, E1 A2, TS1 A2, E1 S2, TS2 S2, E2 A2, TS1 A2, E1 A7, TS2 S3, TS2 A7, E1 S3, E2 A7, TS2 A7, E2 A7, TS2 A7, E2

7 Example (Eifel vs. SRD) Allows lost retransmission detection X X X X
Source Destination Source Destination S1, TS1 S1, E1 S2, TS1 S2, E1 X X S3, TS2 S3, E1 A2, TS1 A2, E1 S4, TS2 S4, E1 S5, TS2 S5, E1 A2, TS1 A2, E1 S6, TS2 S6, E1 A2, TS1 A2, E1 A2, TS1 A2, E1 A2, TS1 S2, TS2 A2, E1 S2, E2 X X S7, TS2 S7, E2 A2, TS1 A2, TS1 A2, E2

8 Moving forward… Less overhead than RFC7323 Timestamps
Solves the retransmission ambiguity problem completely More Complex scenarios involving Fwd Loss / Fwd Reordering / ACK Loss / ACK Reordering Enables Lost Retransmission Detection (LRD) while strictly adhering to packet conservation principles QUIC has similar “control sequence number” Next steps Received initial feedback (clarifications) Eventually asking for adoption


Download ppt "Spurious Retransmission Detection (SRD) with the TCP Echo Options draft-zimmermann-tcpm-spurious-rxmit Richard Scheffenegger <rs@netapp.com> Alexander."

Similar presentations


Ads by Google