Subject: [Tsvwg] Slides for Eifel Response in Vienna IETF

From: Andrei Gurtov <[email-masked]>
Date: Thu, 17 Jul 2003 17:33:10 -0700

Slides for the presentation on Eifel Response in the TSVWG meeting in 
Vienna IETF are available at:

http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.pdf
http://www.cs.helsinki.fi/u/gurtov/reiner/eifel_alg_ietf57.ppt

Also of possible interest is:

A. Gurtov, R. Ludwig, Responding to Spurious Timeouts in TCP, IEEE 
INFOCOM'03, March 2003.
http://www.cs.helsinki.fi/u/gurtov/papers/resp.html

Reiner&Andrei

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: [email-masked]
Date: Fri, 18 Jul 2003 11:28:50 -0500

As I was going through these slides, I didn't even see a single mention of DCLOR, which was the main reason why we had the discussion about appropriate congestion response and rate halving.  In fact, just a couple of months back, most people (including Reiner Ludwig) were not even willing to consider rate halving (I've put links to the e-mails that were exchanged on this issues).

The present DCLOR draft already does what the updated Eifel response will do (the present draft has not even been updated with these changes and the document is being asked for last call). Also, if I can recall, people who engaged in the discussion that time did agree to having two different response algorithm--one as described in the Eifel response --03 draft, and another one which will rate halve every RTO as in DCLOR.

Now, Eifel Response incorporates the work of DCLOR, and makes it look as if they are the ones who came with this scheme in the first place (Here is a link to Reiner's view in March about Rate Halving: http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg03819.html). I had asked the working group chairs in the past about making DCLOR a working group draft, but I did not receive any response. To me all this seems a little strange, and disheartening.

--yogesh 

Please follow the thread of this e-mail for the discussion.

http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg03813.html

> -----Original Message-----
> From: ext Andrei Gurtov [mailto:[email-masked]]
> Sent: 17 July, 2003 7:33 PM
> To: [email-masked]; Reiner Ludwig
> Subject: [Tsvwg] Slides for Eifel Response in Vienna IETF
> 
> 
>

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 21 Jul 2003 06:11:25 +0200

At 18:28 18.07.2003, [email-masked] wrote:
>Now, Eifel Response incorporates the work of DCLOR, and makes it look as 
>if they are the ones who came with this scheme in the first place

No.

Not to confuse things: the "new" thing about the Eifel Response is that the 
stored congestion control state is decayed every RTO. A simpler version of 
that idea had already been part of the original proposal described in our 
CCR 30/1 paper. It was even included in 
draft-ietf-tsvwg-tcp-eifel-alg-00.txt. However, after some debate, we 
decided to take it out in the following revisions of the I-Ds.

In further discussions, including those in which you were involved, we were 
again convinced to include this feature, but in a form similar to the CC 
state decay algorithm specified in RFC2861.

Still, a typo slipped into the slides we showed at the last IETF. To be 
really compliant with RFC2861, the slides should have said:
     Every RTO (non-backed-off !!) counting from 1st Timeout:
     pipe_prev <- max (3/4 * pipe_prev, SMSS)
instead of
     Every RTO (non-backed-off !!) counting from 1st Timeout:
     pipe_prev <- max (pipe_prev/2, SMSS)

///Reiner