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

From: Mark Allman <[email-masked]>
Date: Sun, 13 Jan 2002 13:15:32 -0500

> 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.

Maybe you cannot.  I see a ton of work here.  Reiner's idea of
re-seeding the RTO algorithm with the RTT of the spike is
interesting.  As far as I can tell nobody has tried to characterize
these delay spikes all that well.  Are they a little bigger than the
RTO?  A lot bigger than the RTO?  I am sure someone could come up
with examples of both.

There could be cases when a TCP would determine that no matter what
is done to the RTO it will never be able to stop spurious
retransmits *and* provide anything resembling reasonable performance
(e.g., if the spike is 10 times the RTO).  On the other hand, I can
envision cases where the RTO was off by "a little" and we could
tweak the algorithm or re-seed it of something so that we prevent
future spurious retransmits.  I can see a decision on what to do
being based on the size of the RTT spike (and, maybe the past
history of these things).  Point is that the response does not have
to be a simple tweak -- it could be a more complicated decsision.

> 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.

By "reverting the CC state" I assume we are talking setting ssthresh
to the value of cwnd when loss was detected (as that seems to be
what most folks are talking about).  So, we are always going to be
in slow start after a spurious retransmit (not CA).  The question is
whether we slow start to the previous value of cwnd or half that
value.

> 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.

I think this confuses the two things we can do when we detect a
spurious retransmit.  We can use eifel to detect spurious retrasmits
and avoid the go-back-n behavior without reverting the CC state.
(Or, we could keep go-back-n and revert the CC state -- although
that would not seem to make sense.)  I would say that eifel for
avoiding go-back-n is reasonable and safe (as long as there are no
CC changes made).  (This is also modulo the other note on a failure
case for eifel that I have not yet had a chance to think about.)
And, I would agree with you that this is *better* for the network
because we possibly avoid a bunch of unnecessary retransmissions
that cost resources and do no useful work.  This scheme does not
increase TCP's agressiveness from a CC perspective.  This would
simply make TCP smarter about what it sends.

On the other hand, if you want to immediatly revert the CC state you
are being more aggressive than current TCP because you are letting
cwnd grow exponentially for a longer period of time (in the RTO
case).  And, you are reducing the incentive for TCP to make a good
decision about when to retransmit.  In that case I still think we
need some balancing logic that tries to prevent future occurances of
needless retransmits.

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: "Andrei Gurtov" <[email-masked]>
Date: Mon, 14 Jan 2002 10:33:41 +0200

> RTO?  A lot bigger than the RTO?  I am sure someone could come up

Re-seeding the timer with samples from the spike may not be the solution
(recall my comment in the previous mail). The assumption made by the
conventional timer is that current RTT has some correlation to a coming
delay spike. In many cases it does not and thus a different approach
(statistical model?) is needed to predict a next delay spike as you
suggested. I totally agree that it would be nice to know magnitude and
sources of delay spikes in the Internet and are they correlated to RTT.
However, as we discussed before it may a challenging task. At the moment
there seems to be at least two real, understood and quite different
instances to work with: 1) delay spikes that several times exceed RTT (GPRS)
and 2) moderate  delay jumps due to "bandwidth oscillation" (found by Farid
for cdma2000). In both cases it seems that delays are independent of current
RTT...

> whether we slow start to the previous value of cwnd or half that

I don't think setting ssthresh to the old value of cwnd is a truly general
solution. Consider e.g. TCP connection starting up on a 100-KB
delay-bandwidth network and experiencing a spurious timeout. Would you set
ssthresh to 10 KB or so rendering the connection to dwell in congestion
avoidance for the rest of its life and severely underutilize the link? The
issue here is a spurious timeout by its own a sound indication of a
congestion? Should we instead wait for a packet loss and then slow down?
Based on that, I was speaking of reverting both ssthresh and cwnd.
Independently on whichever we do,  we do not want to send packets at the
twice rate immediately after a spurious timeout if connection was in CA
since the bottleneck queue is filled with old packets. Continuing in CA or
skipping some ACKs until flight<cwnd (not transmitting anything on them)
rather than slow-starting to some ssthresh (transmitting a bunch of packets
at twice rate and then switching to CA) preserves packet conservation.

> simply make TCP smarter about what it sends.

I referred to Eifel as resuming with snd_max and fully reverting CC. It may
be that reducing number of unnecessary retransmissions buys you enough to
also revert the CC state? Still, talking about being more aggressive may not
apply here if we think of a lost packet (or ECN) as the only real indication
of congestion.
It seems that rfc2988 with patches from the tech report is quite
conservative and the sender is unlikely to go into chain of spurious
timeouts. It may well be that letting Eifel to handle occasional delay
spikes is a better solution than to invent some overly complicated timer to
predict them.

Andrei

---

From: "Andrei Gurtov" <[email-masked]>
Date: Mon, 14 Jan 2002 11:10:49 +0200

Unfortunately, I forgot an important comment.

Reverting CC state is in a way tightly coupled with preventing go-back-n,
because setting snd_nxt to snd_max reverts the estimate of the flight size
as well! This is a crucial thing to do since vanilla TCP makes an assumption
that all segments outstanding before the timeout have left the network and
it's not the case after a spurious timeout. If flight size is reverted,
fully restoring CC (both cwnd and ssthresh) does not lead to unwanted
bursts. If CC is not reverted, then a part of ACKs returning after the delay
spike ends are ignored until the flight size reaches the reduced value of
cwnd. If cwnd is a half of the value before the spurious timeout, you are
idle for half of RTT. If CC is not reverted (cwnd is one), you end up being
idle until all packets drain from the network.

Andrei