Subject: Re: [Tsvwg] Eifel draft and usage of time-stamps.

From: Mark Allman <[email-masked]>
Date: Fri, 11 Jan 2002 07:20:53 -0500

> As far as I know, all TCP implementations nowadays have only 1 RTO
> calculation algorithm builtin.  Does it make sense for TCP to
> completely switch to another RTO calculation algorithm given
> certain conditions, or given some hints from outside, say from
> apps?

You wouldn't necessarily need to choose a different algorithm on the
fly.  You could do any number of "tweaks" to the current algorithm
to try to avoid future spurious timeouts.  One simple thing could be
to raise the minimum RTO a little each time you needlessly
retransmitted.  I haven't thought about the RTO case in great
detail.  (However, Ethan Blanton and I have been thinking about the
fast retransmit case quite a bit and I should be able to post a
paper that will appear in the Jan/2002 issue of CCR here in a day or
so.)

The current situation is that if you send a needless retransmit (and
hence add a packet to the network that accomplishes no new work) you
pay a price -- i.e., you slow down.  Now if we make TCP realize this
and undo things the price has been substantially reduced.  So, there
is really no incentive to try to be conservative and easy on the
network.  Therefore, it seems to me (and others I have chatted with)
that in addition to reverting to old CC state and generally being
more aggressive after you detect a spurious retransmit you also need
to take some sort of action to try to prevent future spurious
retransmits (whether that be to use a different RTO algorithm or
increase the dup ACK threshold or increase RTOmin or whatever).

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

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

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 11 Jan 2002 16:15:59 -0800 (PST)

> retransmitted.  I haven't thought about the RTO case in great

Raise RTOmin to 5s then (-:  At least to me, the usefulness of
RTT sampling and RTO calculation as described in RFC 2988 decreases
as the RTOmin keeps increasing as it just masks everything!  The 
point I am trying to raise is that the RTO algorithm in RFC 2988 
should not be the end of all (Reiner should agree (-:).  And I feel,
just me (-:, that other algorithms are probably needed in different
situations.  For example, the basic assumption that the round trip 
route stays pretty much the same does not universally hold true 
nowadays.  This is why I hope researchers in this list can give
some advice.

> paper that will appear in the Jan/2002 issue of CCR here in a day or

Do you have evidence that the problem related to fast retransmit
is significant?  The problem with timeout is very clear and people 
are seeing it very often in the wireless world now.  I guess it 
needs more attention and should be addressed asap...  But please do
update the list on your findings.

> network.  Therefore, it seems to me (and others I have chatted with)

I don't understand the comments above.  If TCP can know for sure
that it just has done a spurious retransmission, it should undo
it.  I agree totally.  But it does not mean that there is no 
incentive to try to be conservative.  At least to some people, the 
issue with it is that what if TCP makes mistakes too often and does
not react to real network problems as it does today.  If all routers
now "punish" overly aggressive TCP traffic, the incentive to be

> increase the dup ACK threshold or increase RTOmin or whatever).

I agree with the above.  But do they really need to go together?
That's my question.  They can be deployed separately.  My issue
with new algorithms is that we need time to really see what they
are doing.  And if there are multiple things going on, some
effects may be masked and we cannot correctly determine some
underlying problems.

							K. Poon.
							[email-masked]

---

From: "Andrei Gurtov" <[email-masked]>
Date: Sun, 13 Jan 2002 17:51:32 +0200

Mark Allman wrote:

> retransmitted.

In case when delay spikes exceed the normal RTT by several times and occur
at random intervals I don't see how VJ timer could be adapted except making
it non-decreasing i.e. estimating the MAX possible RTT on the path.

The RTO value with VJ timer peaks shortly after a spurios timeout and then
it gradually decreases back to normal RTT. You may need to do something
competely opposite:  keep the RTO low immediately after the spurious timeout
to repaire lost segments if fast retransmit, etc. fail. Then, gradually
increase the timer as time goes and probability of a delay occurance rises.

>And, just so we're clear my own opinion is that reverting CC state
>is not safe unless some action is taken such that the chance for
>spurious retransmit (RTO or FR) in the future is reduced.

Reverting CC state does not necessary makes you more aggressive. Imagine a
connection in congestion avoidance that experinces a spurious RTO and goes
into go-back-N using slow start. This can easily lead to congestion losses
since the bottleneck is filled with old packets and retransmissions are send
at twice higher rate. When CC state is reverted, the connection continues in
CA that preserves packet conservation.

Because of that I think Eifel is *more conservative* than vanila TCP in
loading the network. If connection has say a 10-segment window, then Eifel
could detect 10 spurious timeouts paying the same price in terms of
unnecessary retransmissions as vanila TCP does for a single timeout.
Consequently, deploying Eifel with the rfc2988 timer should be safe (and
even good) for network. Of course, I'm not against searching for a better
algorithm for RTO estimation.

Andrei