Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-tcp-eifel-response-04

From: Mark Allman <[email-masked]>
Date: Thu, 11 Dec 2003 08:40:58 -0500

> The chairs would like to announce a two-week Working Group Last Call
> for draft-ietf-tsvwg-tcp-eifel-response-04, commencing on November
> 26th and concluding on December 10th. Please send any final comments
> relating to this document to the TSVWG mailing list.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-response-04.t
> xt

I'm a day late.  What's new?!

For the most part I think this document is in quite good shape and
should be forwarded.  

One thing I am sort of muddled on:

  - Section 4.  Hm.  I guess I am OK with this.  I always worry about
    documents that say "you can do X" without really specifying a way to
    do it.  But, we have done this before and I guess things have been
    scoped tightly enough to make it OK.  I am flagging this for two
    reasons:

      - My thinking is fuzzy here as to whether this is OK or not.  And,
        if anyone else has thoughts I think I'd love to hear them.

      - I do wonder, however, if it would be good to say something to
        the effect that we expect such algorithms to be brought up in
        the IETF.  Does that make sense?

    A less fundemental issue: You mention that RFC3517 is conservative
    in that it has a dupthresh.  But, some think that is a feature not a
    bug (i.e., when we mentioned removing that from the draft of 3517 a
    number of people yelled).  So, I'd like to see some words stating
    the other side of the case (i.e., you have given one side, but I'd
    like to see something that says triggering on one dup ack has its
    own set of issues).

Two things I think need attention:

  + In (STO.2) I think you should also include the bounds checks from
    (2.4) & (2.5) of RFC2988.  I.e., if the RTO becomes too big or too
    small then it should be tweaked.  (You don't have to include a huge
    explanation.  I think it'd be fine to note that RFC2988 includes
    bounds checks that should be applied.)

  + In section 3.1 you note that the Eifel algorithm is used in response
    to "loss recovery".  I'd prefer to see the language in the paragraph
    (second in 3.1) scrubbed to clearly indicate that you mean loss
    recovery detected by the RTO.

And, then a few smaller comments that are not fundemental.  I think they
should be made, but ultimately if they are not the document is still
OK and should move forward.

  = When discussing terminology you might note that IW is currently
    defined in RFC3390.

  = In (STO.1) I'd change "off the top" to "of previously unsent data"
    to make it explcitly clear what you mean.

  = In (STO.2) you should define "G" (the granularity, I assume).  

  = In (ReCC) please define "bytes_acked".

  = In (CVW) it'd be nice to do a sentence that remind us what 'T_last'
    and 'tcpnow' actually mean (for the feeble minded like me!).

  = In section 3.2: "approach would be in place" --> "approach should be
    in place"

  = In 3.3.2: "likely to be off" --> "likely to be inaccurate"

  = In 3.3.2, second paragraph: it'd be nice to include a reminder that
    you're hacking the RTO components in this way because you don't have
    an accurate RTT-SAMPLE to go off of.

  = I'd re-title section 4.  Maybe just drop "Non-Conservative".
    Something, though... it is pretty confusing.

I hope this is useful.  And, I hope the document can be forwarded for
RFC publication very soon.  It's time.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

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

---

From: Reiner Ludwig <[email-masked]>
Date: Thu, 11 Dec 2003 17:13:57 +0100

Hi Mark,

thanks for your detailed review! All good points.

A few comments to your comments below ...

Jon, do you want me to submit a revised I-D, or is it OK to do the changes 
after we got feedback from the IESG?

At 14:40 11.12.2003, Mark Allman wrote:
>   - Section 4.  [...]

I don't know since I don't know anybody at the moment who would like to 
pick this up. What if it never happens?
As you say, we have it tightly scoped. So, maybe that's sufficient?

>     number of people yelled).

We wrote:
    "However, in a more recent study [GL03], we found that the mentioned
    advanced loss recovery schemes are often too conservative to compete
    against TCP-Reno's blind go-back-N in terms of quickly recovering
    multiple losses after a spurious timeout."

This is not saying that RFC3517's use of dupthresh is a bug. In fact, I 
also think it's a feature. It's just that in this particular situation, 
loss recovery after a spurious timeout, RFC3517 is often too slow to 
compete against Reno, and only in that situation do we suggest (in 
different words) to set dupthresh to one with RFC3517.

>So, I'd like to see some words stating

Hmmm, I'm not yet convinced that such text should be added. I think that 
the "other side of the case" would refer to setting dupthresh to one during 
"normal" fast recovery, i.e., not involving a spurious timeout. But, that's 
out of scope for this doc. Don't you agree?

>     bounds checks that should be applied.)

OK.

>     recovery detected by the RTO.

OK. This is a leftover from previous versions that also dealt with spurious 
fast retransmits.

>OK and should move forward. [...]

All good points. I will change the text accordingly.

///Reiner

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 Dec 2003 11:57:26 -0500

Reiner-

> This is not saying that RFC3517's use of dupthresh is a bug. In fact,
> I also think it's a feature. It's just that in this particular
> situation, loss recovery after a spurious timeout, RFC3517 is often
> too slow to compete against Reno, and only in that situation do we
> suggest (in different words) to set dupthresh to one with RFC3517.

But, the document says that reno is twice as fast as it should be (i.e.,
violates packet conservation).  So, is it fair to compare 3517 against
reno in terms of performance?

> Hmmm, I'm not yet convinced that such text should be added. I think
> that the "other side of the case" would refer to setting dupthresh to
> one during "normal" fast recovery, i.e., not involving a spurious
> timeout. But, that's out of scope for this doc. Don't you agree?

Not what I meant.  Sorry.

The draft says the problem with 3517 "is that it waits for three SACKs
before it retransmits a lost segment".  And, in response to that I say,

  * Yes, but that makes it more robust to reordering (per the
    community's current consensus on that topic, I think).

  * And, if this is a "problem" after an Eifel response then why isn't
    this a "general problem"?

Maybe I just don't understand.  Maybe you just need some more words to
indicate why this case is different from more routine cases of loss
recovery and so why it needs treated differently.

In thinking about this and looking back over the draft, I think for me
the last sentence I wrote is key.  I think you should have to say why
this situation is different from usual loss recovery and therefore why
TCPs should be allowed/encouraged do something different in their loss
recovery than they would otherwise do.  If you can't make a clear
statement about that then perhaps none of this belongs in this draft
(i.e., then its just about "loss recovery" and really has little to do
with the Eifel response).

If you can write that down and show this is the case then I very well
might agree with you -- but, I do not yet understand the need.

Thanks!

allman

---

From: Reiner Ludwig <[email-masked]>
Date: Sat, 13 Dec 2003 21:15:32 +0100

Hi Mark,

The thinking behind Section 4 is as follows:

If you are concerned that spurious timeouts in TCP may be a problem in a 
certain network environment then you should find that the Eifel Detection & 
Response is an effective solution. Ideally, you should still think that 
it's an effective solution if you have an environment where the spurious 
timeouts often coincide with multiple losses from the same flight of packets.

But that's the problem. In the latter environment you can be better off 
performance-wise with pure Reno, i.e., is such environments Reno often 
out-performs Reno-Eifel. Even worse in such environments pure Reno often 
even out-performs RFC3517 (with or without Eifel) and NewReno-Eifel. So, 
you might think: "why bother using Eifel?".
[In fact, in such environments you might also think: "why bother using 
RFC3517?"]

As we wrote in Section 4, the reason for this "advantage" is Reno's blind 
go-back-N phase after a spurious timeout during which it breaks 'packet 
conservation'. So, it's an unfair advantage.

We want to remove Reno's unfair advantage by promoting non-conservative 
loss recovery *after spurious timeouts* as outlined in Section 4. Then the 
statement "Eifel is an effective solution in environments with frequent 
spurious timeouts" would hold in general, i.e., independent of whether the 
spurious timeouts often coincide with multiple losses, or not.

Had we put into RFC3517: "you MAY set dupthresh to 1 during loss recovery 
after a spurious timeout" then there would be no reason to include Section 
4 in draft-ietf-tsvwg-tcp-eifel-response.

Does this make it clearer? If yes, what's missing in Section 4?

Coming back to something you wrote in a previous mail:
    'I always worry about
     documents that say "you can do X" without really specifying a way to
     do it.'

We didn't think about it before, but maybe one way to go in this Section 4 
is to promote the use of RFC3517 with the addition that "you MAY set 
dupthresh to 1 during loss recovery after a spurious timeout". What do you 
think?

///Reiner

---

From: Mark Allman <[email-masked]>
Date: Mon, 15 Dec 2003 10:04:00 -0500

Reiner, Jon-

After re-reading Reiner's note, section 4 of the Eifel reponse draft and
making a pass at [GL03] (Gurtov/Ludwig, Infocom 2003) my own opinion
about the draft being forwarded is:

    I believe the actual Eifel response specified in the document is
    well done.  I believe it is clear, well-motivated and safe.
    However, I do not feel that the loss recovery modifications
    presented in section 4 of the document are either in-scope for the
    Eifel response nor are they appropriate changes to TCP loss
    recovery.  Therefore, my own preference is for the document to go
    forward without section 4 (and, with several other agreed upon
    tweaks that I sent last week).

Having said that, a few more detailed responses/points.

First, I find nothing fundementally different about loss recovery after
a (detected) spurious timeout than at any other point in the connection.
When I originally read the draft I thought that somehow the Eifel
response had created a unique situation in TCP that would require (or at
least make desireable) some different form of loss recovery.  However,
from deeper thinking and more reading I cannot actually see such a
unique situation.  So, my opinion is that the Eifel response should say
nothing about loss recovery (i.e., changing loss recovery is
out-of-scope).

I am not saying that the Eifel response does not *impact* loss recovery.
I.e., if you compare reno to reno-with-eifel to sack to sack-with-eifel
you may see different performance.  I agree.  But, that by itself does
not argue that some form of advanced loss recovery is more or less
appropriate.

> We didn't think about it before, but maybe one way to go in this
> Section 4 is to promote the use of RFC3517 with the addition that "you
> MAY set dupthresh to 1 during loss recovery after a spurious
> timeout". What do you think?

I do not agree with this.

I thought of this little scenario: Let's assume that this document (as
is) becomes standard TCP behavior.  And, further, that a student comes
to me and says "hey, why is the dupthresh 1 here and 3 there?".  I don't
have a good answer to that question.  If there was some unique situation
created by the Eifel response so that I could say "because the Eifel
response forces X and to deal with that we change dupthresh to one and
it's OK because of Y" then that might be OK.  But, from just looking at
such a TCP connection trace it would not seem evident that the dupthresh
should be different at different places.  So, to me that says it should
not be.

Yes, one could explain it with a history lesson.  But, I am not sure
that the punch-line of the history lesson about reno and go-back-n is
that dupthresh should be one not three.  That takes a leap I am not
willing to make.  (Basically, you have argued that reno got it wrong in
a number of ways (blind retransmission/go-back-n and breaking packet
conservation).  I buy that assertion.  But, given that it got it wrong I
am not necessarily willing to believe that it is the blue-ribbon
standard that we should be shooting at.  That doesn't necessarily seem
appropriate to me.)

And, two practical (i.e., non-philosophical) points...

  * I do not really understand why RFC3517 is going to take a whole lot
    longer with a dupthresh of 3 as opposed to 1.  In the worst case
    where there is a massive hole in the sequence space and only one
    SACK block above it then you will likely see worse performance with
    dupthresh=3 than with dupthresh=1 (because at a minimum you'll take
    two RTTs to determine a lot of loss happened; and in doing so a
    timeout may occur).  But, I doubt this is the common case.  And, the
    case can actually happen anytime -- and, it stinks no matter when it
    happens.  Why is it different if it happens immediately after a
    detected spurious timeout?  I can't figure out that it does.

  * What is not mentioned in the i-d is that a dupthresh of one makes
    TCP less robust to reordering.  Not that TCP is wonderfully robust
    to reordering now.  But, I think we formed consensus when we wrote
    3517 that threshold retransmission was the way to go.  Further, some
    of the studies of reordering in the wild (e.g., the Partridge,
    et.al. paper in ToN in Dec/1999) suggest that reordering and
    congestion are correlated.  So, if you have loss you may be more
    likely to also have reordering.  Hence, it might not be the time to
    reduce TCP's (limited) ability to cope with reordering.  One could
    sketch a case with reordering during this phase of the connection
    that may well yield performance implications just as bad as the
    worst case from the above bullet, IMO.

All things considered I just don't understand why this section should be
included in the document to begin with.  And, then I don't agree with
the mechanism that is included.  So, FWIW, I vote to remove section 4.

Thanks!

allman

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 18 Dec 2003 15:29:33 +0200

Mark-

Sorry for joining the discussion late, but I think that Section 4 should 
  be kept in, perhaps in somewhat revised form.

Reno+SACK+TS after a spurious timeout uses "informed" go-back-N, i.e. it 
retransmits outstanding packets using slow start while skipping those 
packets that were known to be received by the sender (at least from the 
point when ACKs for original segments stop arriving). This approach 
recovers without a genuine timeout even if all but the oldest 
outstanding segment are lost.

With Reno+SACK+TS+Eifel the transmission is resumed from the top and the 
loss recovery is based on fast retransmit and fast recovery that are 
less robust than Sack go-back-N. In particular it's needed to get three 
DUPACKs (which even with LT may require waiting for 3 RTTs) and 
Reno-Sack is likely to experience a genuine timeout in fast recovery in 
the presence of a significant amount of losses. This makes 
Reno+SACK+TS+Eifel more succeptible to genuine timeouts than 
Reno+SACK+TS that motivates the need for more effective loss recovery 
with Eifel. "Effective" does not need to be reducing dupthresh to one, 
but using NewReno-SACK is a good approach based on our experiements.

Another reason for effective loss recovery with Eifel is that if the 
retransmit timer is made more conservative to avoid future spurious 
timeouts, then genuine timeouts should be prevented as much as possible 
because they are very costly.

Andrei

---

From: Mark Allman <[email-masked]>
Date: Thu, 18 Dec 2003 10:47:22 -0500

Andrei-

Thanks for the note.

> I think that Section 4 should be kept in, perhaps in somewhat revised
> form.

What sort of revision would you suggest?  I didn't see anything in your
note that deviated from the draft so I am confused.
 
> Reno+SACK+TS after a spurious timeout uses "informed" go-back-N, 
>
> [...]
>
> With Reno+SACK+TS+Eifel the transmission is resumed from the top 

Right.  That seems like the key difference to me.  But, I don't
understand why that means that a different loss recovery strategy is
in order (see below).

> In particular it's needed to get three DUPACKs (which even with LT may
> require waiting for 3 RTTs) and Reno-Sack is likely to experience a
> genuine timeout in fast recovery in the presence of a significant
> amount of losses. This makes Reno+SACK+TS+Eifel more succeptible to
> genuine timeouts than Reno+SACK+TS that motivates the need for more
> effective loss recovery with Eifel.

I don't believe this.  Sending "from the top" should trigger duplicate
ACKs, too.  And, those ACKs will help loss recovery along just fine.

The only cases when 1 dupack is better (by any significant amount) than
3 dupacks is (a) when the window is really small or (b) when a massive
amount of the window (or the corresponding ACKs) is lost.  But, both of
these are general issues.  The fact that the eifel response calls for
sending off the top does not matter because these segments still trigger
dupacks (/SACKs).  I do not think that Eifel vs. non-Eifel makes any
difference in what the appropriate loss recovery strategy should be.

So, let me try to be very clear: It's not that I believe these general
issues are not important.  To the contrary I have assisted on limited
transmit and early retransmit to combat these sorts of situations.  It's
just that I do not believe there is anything Eifel-specific in the
issues and therefore I think they should be addressed in a general way
and not in the back of the Eifel response document.

> timeouts, then genuine timeouts should be prevented as much as
> possible because they are very costly.

This seems backwards to me.  I think of RTOs as costly in any situation
and so they should be avoided as much as possible.  I would not say that
the Eifel response makes the RTO "more conservative".  I would say that
the Eifel response makes the RTO "appropriately conservative".  In other
words, the RTO pre-Eifel was not correct (too aggressive), the
connection figured this out and reset the RTO to something that is more
legitimate.  So, I don't understand how this adjustment to make the RTO
accurate again is a reason to be more aggressive in our attempt to avoid
RTOs.  (Put another way the new timer is only "more conservative" when
looked at in relation to something that was provably busted.  So, why is
this busted RTO a valid point of comparison?)

Thanks,
allman

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 19 Dec 2003 16:36:01 +0200

> note that deviated from the draft so I am confused.

Actually I'm happy with the present form. I just wanted to say that we 
are open minded about making a change if you think it's necessary.

 > understand why that means that a different loss recovery strategy is

Eifel is meant as a peformance enhancment, but if it's enabled with a 
Sack TCP connection running over a path with delay and losses it could 
actually *decrease* TCP throughput and goodput. Therefore I think it's 
reasonable to mention this problem in the document and recommend use of 
more effective error recovery strategies that allows Eifel to *improve* 
performance (to a greater extent than just the use of those recovery 
strategies alone would do).

 > ACKs, too.  And, those ACKs will help loss recovery along just fine.

True, but the problem with conservative Sack is that it often gets a 
genuine timeout on the first partial ACK because it assumes that lost 
segments are still in the network and the sender cannot retransmit packets.

 > difference in what the appropriate loss recovery strategy should be.

While it doesn't make difference in the *type* of appropriate loss 
recovery it does make difference on its *level* of importance. As a 
hypothetical example, consider that Sack TCP gets x kbps throughput, 
Sack+Eifel gets x-30% throughput, NR-Sack gets x+10% kbps and 
NR-Sack+Eifel gets x+100% kbps. Wouldn't it be wrong not to tell people 
that they *really* consider use of something else than Sack with Eifel 
because it makes a big difference in performance, although you are right 
that it might be a useful mechanism on its own?

 > and not in the back of the Eifel response document.

But those "general issues" happen much more often with Eifel because it 
relies on fast transmit-derived recovery while standard Sack relies on 
"informed" go-back-N. I do believe that effective loss recovery is in a 
way *required* with Eifel. While we don't go in great detail of 
describing it in the document, we just mention the problem and suggest 
possible solutions.

 > this busted RTO a valid point of comparison?)

How about if link RTT is 1 second and the there are ocassional delay 
spikes of 10 s. Let's say the min RTO value is adapted to 10 s after a 
spurious timeout with Eifel. Then, any loss recovery through timeouts 
would be very inefficient (because "legitimate" RTO should be still 1 s 
in most of the time) and this is why a specific recommendation for use 
of effective loss recovery I believe is needed in the document. Without 
Eifel, a Sack TCP would be fine because it uses go-back-N and doesn't 
adapt the timer so it better avoids genuine timeouts *and* they are less 
costly than for Eifel.

Andrei

---

From: Mark Allman <[email-masked]>
Date: Fri, 19 Dec 2003 10:47:55 -0500

Andrei-

Thanks for the note.

I think we have two different points of view here that are fundementally
different and will prevent us from converging.  You seem to be
interested only in improving performance over current TCP.  I agree that
undo-ing sub-optimal performance caused by spurious timeouts is a good
goal - even the primary goal.  But, if there are cases when we do the
Right Thing to the "detriment" of performance that seems fine, too.  To
be clear we're not talking about all of Eifel here.  If Eifel always
degraded performance than maybe there would be no reason for it (or,
maybe there would be ... we could debate that, but it is academic at
this point).  We're only talking about Eifel when spurious timeouts and
loss are mixed together.

My fundemental problem with this entire line of thinking is my read of
your comments and your draft as conflicting.  On the one hand, you note
that TCP's behavior is inappropriate after a spurious timeout (by using
go-back-n to needlessly retransmit and by using slow start which piles
too much into the network).  Meanwhile, on the other hand, you are using
the current (broken) TCP as the blue-ribbon standard and saying that we
**need** performance that is at least as good if not better than current
TCP.  I cannot make those two lines of thinking converge in my head.  It
is a fine goal to improve performance.  But, it is also a fine goal to
transmit appropriately.  If you can improve performance while being
appropriate in your behavior then that's wonderful (e.g., the case of a
spurious timeout, Eifel and no loss).  But, if you can't improve
performance in all cases then I don't think that means Eifel is a
failure.  I.e., we should not measure the goodness of things solely in
terms of performance gain or loss.  There are other metrics that are
important, as well.

Put another way, if I defined a scheme (call it Appalachian - doesn't
roll off the tongue quite as well as Eifel, but the spirit is there ...)
that said:

  If you see a spurious timeout:
    + immediately bump your cwnd & ssthresh back to what they were
      before this unneeded timeout
    + run go-back-n just in case there were losses
    + all the while increase cwnd per congestion avoidance

Well, I'd say Appalachian would be a performance win over current TCP.
Would that be OK?  I hope we can agree that it would not be.  And, it's
not OK because performance is not the only metric we care about.

> segments are still in the network and the sender cannot retransmit

RFC3517 is quite aggressive about declaring things to have left the
network within the confines of threshold retransmission (mostly) --
which is what I believe the community consensus was and is.  I would be
a little surprised (although not completely shocked) if you found a case
when RFC3517's notion of the data still in the network is badly broken.
And, furthermore, even if a TCP cannot retransmit because of threshold
retransmission it can still send new data (and, if it can't send new
data then threshold retransmission can be turned off).  So, the
connection is still making progress.

I keep coming back to RFC3517 because Reiner offered that maybe your
draft should say "use RFC3517 with a dupthresh of 1" (para-phrasing my
impression of what Reiner said; I am too lazy to look up the exact
words).  Maybe that is not your opinion.  But, I really don't understand
what the practical difference between dupthresh=1 and dupthresh=3 is in
terms of RFC3517 performance (except when faced with reordering).

Thanks,
allman

---

From: Andrei Gurtov <[email-masked]>
Date: Fri, 19 Dec 2003 18:08:43 +0200

> terms of performance gain or loss.  There are other metrics that are

It appears the performance in this content refers to throughput. In our 
simulations using Eifel *with* effective loss recovery improved both 
throughput *and* goodput of TCP. Better goodput means that less segments 
  are required to complete a connection = less load on the network. In 
the opposite, without effective loss recovery throughput *and* goodput 
are reduced.

> not OK because performance is not the only metric we care about.

That's certainly not what we want. Another extreme case would be just to 
use stop-and-wait by sending a single packet at a time and waiting for 
ack before transmitting a new one.

> connection is still making progress.

I think RFC3517 makes conservative assumptions which is fine, but it's 
really useful to relax them for error recovery after a spurious timeout 
with Eifel.

Andrei

---

From: Mark Allman <[email-masked]>
Date: Fri, 19 Dec 2003 11:19:03 -0500

> It appears the performance in this content refers to throughput. In
> our simulations using Eifel *with* effective loss recovery improved
> both throughput *and* goodput of TCP. Better goodput means that less
> segments are required to complete a connection = less load on the
> network. In the opposite, without effective loss recovery throughput
> *and* goodput are reduced.

I'd rather not get into this, but the simulations of yours that I have
read about do not include reordering -- which is what using a larger
dupthresh buys you protection against.

> really useful to relax them for error recovery after a spurious
> timeout with Eifel.

And, I don't think your simulations backup that statement because I
don't think you used RFC3517.

That is not to say:

  + That your simulations are junk.  All simulations lack realism in
    some way or another.  But, your simulations do not (IMO) speak to my
    point that threshold retrannsmission buys us something.

  + That is not to say that RFC3517 is mandatory.  Or, that there are
    not other schemes that might be better or worse or perform
    differently in this case.  But, trying to discuss them has a certain
    amount of fuzziness to it because they are not well specified, while
    RFC3517 is.

  + Reiner brough up the possibility of explicitly saying RFC3517 with
    dupthresh=1.  And, so I am working off that and trying to understand
    what that might buy us -- and, from what I can see it would be very
    little.

allman

---

From: "Andrei Gurtov" <[email-masked]>
Date: Mon, 22 Dec 2003 17:14:14 +0200

> dupthresh buys you protection against.

It seems that having delays, losses *and* reordering at the same time may
not be a common case. Furthermore, Linux TCP (that uses FACK by default)
falls back to conservative SACK if any reordering is detected on a given TCP
connection. If NewReno-SACK that is recommended by us has any trouble with
reordering (I'm not sure it does) then it could do the same.

> don't think you used RFC3517.

We've used SACK from ns2 which is fairly close to RFC3517. Presumably, it's
the responsibilty of RFC authors to keep the ns2 implementation up to date.

I feel that arguments provided so far fairly well motivate the need of
effective loss recovery with Eifel. So it looks to me as though there is
lobbying against mentioning anything else but conservative SACK in RFCs.

Andrei

---

From: Mark Allman <[email-masked]>
Date: Mon, 22 Dec 2003 18:05:45 -0500

Andrei-

> We've used SACK from ns2 which is fairly close to RFC3517.

Actually, it is not.  They are similar in spirit, but not in some of the
fundemental details --- which causes quite different behavior.  For
instance, you can see a section towards the end of the following paper
to see a difference (it is only marginally related to this discussion,
but the point is that the two algorithms are, in fact, quantitativly
different and behaviorly different).

    Mark Allman, Wesley Eddy, Shawn Ostermann. Estimating Loss Rates
    With TCP. ACM Performance Evaluation Review, 31(3), December 2003.
    http://www.icir.org/mallman/papers/least-per-dec2003.ps

> Presumably, it's the responsibilty of RFC authors to keep the ns2
> implementation up to date.

Hm.  I was not aware of this requirement on RFC authors.

> effective loss recovery with Eifel.

I believe it is incumbant on the proposer of a special case in TCP to
clearly motivate the need for the special case.  My opinion is that
section 4 of the draft in question does not fulfill that requirement.
Further, I have talked to several others in the hopes that they might
shed some light on blind spots in my thinking -- but, to my chagrin they
have found section 4 confusing, as well (and, so (to their credit) they
would not weigh in on whether they thought I was right or wrong about
the need for a special case).  (It would, BTW, be nice if others could
voice their opinions on this since my comment here is just hersay.)  So,
I think ***at a minimum*** the draft needs to be updated in such a way
that very clearly motivates the need (or desire) for a special case loss
recovery after a spurious timeout has been detected.  I.e., what sort of
new dynamic does Eifel cause that warrents a special case?

(If you can write such an explanation that'd be wonderful.  Nothing in
our exchange thus far has swayed me that there is an argument for a
special case.  That might actually be just faulty thinking on my part.
If someone can clearly explain that Eifel causes some dynamic that needs
compensated for then I may well be fine with an exception.  It just has
not yet happened.  I've been dense before, though.)

> So it looks to me as though there is lobbying against mentioning
> anything else but conservative SACK in RFCs.

I am not lobbying against any alternate loss recovery.  I am lobbying
against ***special case loss recovery***.  There is a difference.  The
last thing we need to do is to be adding special cases all over the
place.  TCP is hard enough to get right.  I am focused on RFC3517
because:

(a) it is something that is specified and nailed down and can easily be
    discussed in concrete terms (unlike "FACK" or "SACK-NewReno" or
    "conservative SACK" which are all documented to some degree in
    papers or wherever, but are not rigorously outlined --- and mean
    different things inside different people's heads)

(b) Reiner offered that RFC3517 with a dupthresh of 1 in loss following
    the Eifel response would be fine

If the draft says "use of X general loss recovery technique (throughout
the entire connection) works best with the Eifel response" then maybe
that is OK (although, since that X will not be RFC3517 I am sure, that
might get into a "normative reference" sort of issue).  My heartburn is
with the notion that we need to use different loss recovery at different
times.  That seems less than desireable -- and in need of clear and
solid motivation.

allman

---

From: Andrei Gurtov <[email-masked]>
Date: Sat, 27 Dec 2003 16:37:36 +0200

Mark-

>Hm.  I was not aware of this requirement on RFC authors.

Are you saying that RFC3517 went to proposed standard without even an 
existing implemenation? Presumably extensive simulations of different 
possibilities are required before creating this "reference" version. 
It's surpising you did that without having an ns2 implementation.

I think you are more demanding on our draft what is going to 
*experimental* than you were on PS RFC3517.

>new dynamic does Eifel cause that warrents a special case?
I can write a paragraph that would repeat the reasons that I've already 
given 1) reliance of Eifel on fast retransmit/fast recovery rather than 
"informed" go-back-N 2) frequent genuine timeouts for conservative SACK 
3) need for making the retransmit timer more conservative with Eifel to 
avoid spurious timeouts 4) simulation results that show that effective 
error recovery improves throughput and goodput.

I can rerun simulation tests using the exact RFC3517 SACK if an ns2 
implemenation for it would be available.

>place.  TCP is hard enough to get right.  I am focused on RFC3517
IMHO it's a lot of debates that make it look complex. Adding 
NewReno-SACK to ns2 just took few lines of code.

>    different things inside different people's heads)
We can add a strict definition of NewReno-SACK into the draft, but to me 
just a note looks sufficent saying that use of effective  loss recovery 
is advantageous with Eifel. E.g. RFC3168  on AQM does not specifty 
anything exactly, but just discusses related issues.

Andrei