Reiner Ludwig Ericsson Research
7
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research 1 Reiner Ludwig Ericsson Research Eifel Response Algorithm: Ready for WGLC? Andrei Gurtov Sonera Corporation
description
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. - PowerPoint PPT Presentation
Transcript of Reiner Ludwig Ericsson Research
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research1
Reiner Ludwig
Ericsson Research
Eifel Response Algorithm:
Ready for WGLC?
Andrei Gurtov
Sonera Corporation
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research2
Recall: The Problem (Spurious Timouts & Reordering)
24000
29000
34000
39000
44000
49000
54000
27 32 37 42 47 52 57 62Time of Day (s)
Se
qu
en
ce
Nu
mb
er
Snd_DataSnd_AckRcv_DataRcv_AckhiccupTCP Sender Trace
TCP Receiver Trace(offset by +10,000 bytes)
Spurious Retransmitof Entire Flight !!!
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research3
Recall: The Proposed Solution
35000
40000
45000
50000
55000
41 46 51 56 61 66Time of Day (s)
Se
qu
en
ce
Nu
mb
er
Snd_DataSnd_AckRcv_DataRcv_AckhiccupTCP Sender Trace
TCP Receiver Trace(offset by +10,000 bytes)
1. Resolve Retrans. Ambiguity
2. Restore CWND / SSTHRESH&
Update RTT Estimators
3. Resume “off the top”
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research4
To solve the problem you need …
= Published RFC = I-D in WGLC = I-D in progress
3. ResponseE. Blanton &
M. AllmanEifel Response
Reverse CC State
& Adapt
DupThresh
Reverse CC State
& Adapt RTO
1. SignallingTimestamps
RFC 1323DSACK
RFC 2883“Heuristics” The RXT Flag
or or or
2. DetectionEifel Detection
RFC 3522E. Blanton &
M. AllmanP. Sarolahti &
M. Kojoor or
Spurious Timeouts
& Reordering
OnlySpurious Timeouts
Only Reordering
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research5
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
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research6
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
Reiner Ludwig – 57th IETF Meeting, July 2003 Ericsson Research7
Question to the WG:
Given that we Address the Remaining Issues as Outlined, is the Eifel Response I-D Ready for WGLC?
