Subject: RE: [Tsvwg] F-RTO summary

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 18 Oct 2002 10:29:43 -0500

Dear All,

I think Pasi's suggestion for a separate document talking about how to react to a detected spurious timeout, independent of the way it's detected, makes perfect sense.

Dear Pasi,

Is the Eifel Response I-D (draft-ietf-tsvwg-tcp-eifel-response-00.txt) the type of document you're thinking of? I'm focusing on sections 2.2-2.4 and 3, of course...

Spencer

-----Original Message-----
From: Pasi Sarolahti [mailto:[email-masked]]
Sent: Friday, October 18, 2002 6:37 AM
To: [email-masked]
Subject: [Tsvwg] F-RTO summary

Hi,

Thank you to all for comments about F-RTO open issues I presented last 
week. We'll start preparing a new version of the draft based on the 
feedback, but before that, I would like to summarize here what was 
discussed. Please tell, if I have something wrong.

1. Congestion Control. To me this remained somewhat unsolved. Halving 
the window got some support, but on the other hand, some points were 
raised indicating the risks involved in doing so. I would think that at 
this point we leave in the suggestion to halve cwnd and ssthresh, but 
leave the door open for doing something else, for example reverting the 
congestion control state. I think it would be nice to have a small 
separate document giving a recommendation on how to perform congestion 
control in general when spurious RTO is detected by some method, or 
what do you say?

[deleted rest of e-mail]
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 21 Oct 2002 16:25:42 +0300

On Friday 18 October 2002 18:29, ext Spencer Dawkins wrote:

> Is the Eifel Response I-D
> (draft-ietf-tsvwg-tcp-eifel-response-00.txt) the type of document
> you're thinking of? I'm focusing on sections 2.2-2.4 and 3, of
> course...

Something like that, but I was more like thinking of issues discussed 
in Section 2.4 (about cc state) and maybe Section 2.2.2 (on RTT 
estimators), when limited to spurious RTO cases. Reverting congestion 
control would be quite obvious after detecting false retransmits due to 
packet reordering or packet duplication, but RTO triggered by delay 
spike seems to be a more complicated case. Such RTO indicates that some 
network node has not been able to forward packets during the period of 
RTO, thus likely being under some form of increased congestion as a 
result. Moreover, as Yogesh hinted on the list earlier, during the 
spurious RTO the network conditions may have changed, and thus some 
kind of actions on congestion control may be needed.

One option would be to revert congestion control state and wait for 
packet losses or ECN-Echo to take care of congestion control, but I'm 
not sure if it is the right one. On the other hand, that would be 
similar to case in which RTO was not very conservative and did not 
expire spuriously.

- Pasi