Subject: [Tsvwg] new version of early retransmit

From: Mark Allman <[email-masked]>
Date: Thu, 14 Dec 2006 09:04:33 -0500

We recently re-submitted the early retransmit I-D that we pushed along a
while back:
 
        Title           : Early Retransmit for TCP and SCTP
        Author(s)       : M. Allman, et al.
        Filename        : draft-allman-tcp-early-rexmt-04.txt
        Pages           : 10
        Date            : 2006-11-26
        http://www.ietf.org/internet-drafts/draft-allman-tcp-early-rexmt-04.txt

We stopped pushing this I-D because some of our analysis of network
traces seemed to indicate that ER was sort of a crapshoot, failing as
much as succeeding.  However, given that we never went beyond sort of a
preliminary assessment and did not publish the results (/ let them stand
against peer review) we no longer think we should stop the ER draft
because of these results.  Further, the results were from on particular
network and it would seem useful to gain a broad understanding of how ER
works in a variety of environments.

My recollection is that once upon a time the TSVWG had some consensus to
take on ER as a work item with the intention of publishing it as an
experimental RFC.  I am not asking the WG that question right now.  But,
we may ask that question soon, if the chairs are amenable.  Right now we
just want to alert folks that this draft is out and solicit comments
From the WG.

Thanks!

allman

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Dec 2006 10:03:15 -0800

I'm all for looking at early retransmission, but why would this not  
be looked at within tcpm?

One question. The drafts notes that "Research shows that a general  
reduction in the number of duplicate ACKs required to trigger Fast  
Retransmit to two (rather than three) leads to a reduction in the  
ratio of good to bad retransmits by a factor of three [Pax97]."  
Saying that spurious retransmission triples if the number changes  
from three to two doesn't help me much: does that mean that it is 30%  
instead of 10%, 3% instead of 1%, or 0.3% instead of 0.1%? Speaking  
for myself, a heuristic that does the right thing 97% of the time  
seems like a pretty good heuristic, and accepting an additional 2% or  
0.2% spurious retransmission seems a good trade-off for completing  
short transfers more quickly in 97% of cases where a loss occurs. 30%  
vs 10% is of course a different story.

On Dec 14, 2006, at 6:04 AM, Mark Allman wrote:
> We recently re-submitted the early retransmit I-D that we pushed  
> along a while back:
>
> traces seemed to indicate that ER was sort of a crapshoot, failing  
> as much as succeeding.  However, given that we never went beyond  
> sort of a preliminary assessment and did not publish the results (/  
> let them stand against peer review) we no longer think we should  
> stop the ER draft because of these results.  Further, the results  
> were from on particular network and it would seem useful to gain a  
> broad understanding of how ER works in a variety of environments.
>
> My recollection is that once upon a time the TSVWG had some  
> consensus to take on ER as a work item with the intention of  
> publishing it as an experimental RFC.  I am not asking the WG that  
> question right now.  But, we may ask that question soon, if the  
> chairs are amenable.  Right now we just want to alert folks that  
> this draft is out and solicit comments From the WG.
>
> Thanks!
>
> allman
>
>
>

---

From: Mark Allman <[email-masked]>
Date: Thu, 14 Dec 2006 13:39:41 -0500

Fred-

> I'm all for looking at early retransmission, but why would this not be
> looked at within tcpm?

Possibly it should be.  I wonder if the current ADs have a hit.  The
original ER work was done in TSVWG because (a) when we started there was
no TCPM and (b) while we were working and TCPM spun up we decided to
leave it here because it is also useful (or not) for SCTP.  That said, I
do not much care about the venue.

The more technical point I will have to defer until I can remember the
specifics of Vern's paper.

Thanks!

allman

---

From: Mark Allman <[email-masked]>
Date: Thu, 14 Dec 2006 23:06:03 -0500

> ratio of good to bad retransmits by a factor of three [Pax97]."

Yes - that could be a better discussion, clearly.

> Saying that spurious retransmission triples if the number changes from
> three to two doesn't help me much: does that mean that it is 30%

From [Pax97]:

    [N1 & N2 are sets traces taken of 100KB transfers.]

    For current TCP, Nd = 3 dups and W = 0. For these values, we find in
    N1, R_{g,b} = 22, and in N2, R_{g,b} = 300! The order of magnitude
    improvement between N1 and N2 is due to the use in N2 of bigger
    windows (x 2), and hence more opportunity for generating good
    dups. Clearly, the current scheme works well. [...]  For Nd = 2, we
    gain about 65-70% more fast retransmit opportunities, a hefty
    improvement, each generally saving a connection from an expensive
    timeout retransmission. The cost, however, is that R{g,b} falls by
    about a factor of three."

So, a general reduction (according to this old data) would put the
chance of spurious fast retransmit at somewhere between 1% (for N2) and
14% (for N1).  The other note in the above is that bigger windows help
the standard (Nd=3) case quite a lot, suggesting that maybe messing with
the threshold only where it is problematic (i.e., when the cwnd is
small) may be the way to go.

Does that help?

allman

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Dec 2006 07:46:38 +0100

> do not much care about the venue.

Because this applies to SCTP as well, it can't really be in TCPM from  
a charter perspective. Either we leave the current, single document  
in TSVWG and work jointly with TCPM on it, or we split and do a TCP- 
only doc in TCPM and an SCTP one here.

The expertise on this is probably more concentrated in TCPM, so maybe  
I have a slight preference for splitting, doing a TCP-only mechanism  
there first and once that's stable do a smaller document here that  
says "and here's how you do this for SCTP."

I'm interested in comments.

Lars

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 15 Dec 2006 09:46:37 +0200

> only doc in TCPM and an SCTP one here.

From tcpm charter:
"TCP's congestion control algorithms are the model followed by alternate
transports (e.g., SCTP and (in some cases) DCCP).  In addition, the 
IETF has recently worked on several documents about algorithms that 
are specified for multiple protocols (e.g., TCP and SCTP) in the same 
document.  Which WG shepherds such documents in the future will 
determined on a case-by-case basis."

I believe many of the TCP (/SACK) sender algorithms are likely
applicable also to SCTP. F-RTO [RFC4138] and DCR [RFC4653] were done in
tcpm, although both mention SCTP, too (F-RTO even had a dedicated
section for SCTP).

> says "and here's how you do this for SCTP."

I think there would be quite much relative overhead in splitting a
9-page document: two documents with probably not much less than 9 pages,
needing to discuss things in two WGs, and so on.

Proposal: Send the note also to tcpm, and see which mailing list gives
more technical feedback on this version of the draft. (though I guess
most tcpm'ers are also on the tsvwg mailing list)

- Pasi

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Dec 2006 08:57:06 +0100

> determined on a case-by-case basis."

Teaches me to not work from memory :-)

> tcpm, although both mention SCTP, too (F-RTO even had a dedicated

TCPM does seem like the right place for it then.

Lars

---

From: Mark Allman <[email-masked]>
Date: Fri, 15 Dec 2006 10:23:37 -0500

> TCPM does seem like the right place for it then.

I sent my original note over to TCPM just now.  Where this all happens
doesn't much matter to me.

allman