1 / 7

Reiner Ludwig Ericsson Research

Eifel Response Algorithm: Ready for WGLC?. Reiner Ludwig Ericsson Research. Andrei Gurtov Sonera Corporation. Recall: The Problem (Spurious Timouts & Reordering). Spurious Retransmit of Entire Flight !!!. 1. Resolve Retrans. Ambiguity. Recall: The Proposed Solution.

tomai
Download Presentation

Reiner Ludwig Ericsson Research

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. Eifel Response Algorithm: Ready for WGLC? Reiner Ludwig Ericsson Research Andrei Gurtov Sonera Corporation

  2. Recall: The Problem (Spurious Timouts & Reordering) Spurious Retransmitof Entire Flight !!!

  3. 1. Resolve Retrans. Ambiguity Recall: The Proposed Solution 2. Restore CWND / SSTHRESH&Update RTT Estimators 3. Resume “off the top”

  4. Timestamps RFC 1323 “Heuristics” DSACK RFC 2883 1. Signalling or or or The RXT Flag OnlySpurious Timeouts Spurious Timeouts& Reordering Only Reordering Eifel DetectionRFC 3522 P. Sarolahti &M. Kojo E. Blanton &M. Allman 2. Detection or or Eifel Response E. Blanton &M. Allman 3. Response = Published RFC = I-D in WGLC = I-D in progress To solve the problem you need … Reverse CC State& Adapt RTO Reverse CC State& Adapt DupThresh

  5. Eifel Response Limited to Spurious Timeouts • Adapting DupThresh is Controversial • Don’t want to Change DupThresh for Occasional Reordering • When to start Adapting? How? • Do we need a DupThresh Estimator? • More Research Needed! • This Issues was Holding up Progress of the Eifel Response I-D • We will Exclude Adapting DupThresh in the Next Revision • Eifel Response will Only Work for Spurious Timeouts

  6. Addressing the Remaining Open Issues • Decaying of CC state after Detecting a Spurious Timeout • On 1st Timeout (the one that later might be detected to be spurious):pipe_prev  max (FlightSize, ssthresh) • Every RTO (non-backed-off !!) counting from 1st Timeout:pipe_prev  max (pipe_prev/2, SMSS) • On Detecting Spurious Timeout:cwnd  FlightSize + min (bytes_acked, IW)ssthresh  pipe_prev • Adapting RTO in Response to Detecting a Spurious Timeout • With Timestamps:Reseed according to RFC2988: SRTT  R and RTTVAR  R/2 • Without Timestamps :RTTVAR  max (2 * RTTVAR, SRTT) and SRTT  2 * SRTT

  7. Question to the WG:Given that we Address the Remaining Issues as Outlined, is the Eifel Response I-D Ready for WGLC?

More Related