Subject: Re: [tcpm] a different scheme for reacting to spurious RTOs

From: Mark Allman <[email-masked]>
Date: Tue, 01 Nov 2005 16:39:25 -0500

Pasi-

I failed to reply to this note from long ago and apologize.

> How about considering possibility of bounding K somehow, rather than
> letting it increase indefinitely? 

Not until you asked.  But, we have now.

> While sometimes the blocked state can be really long, there also are
> occasions where RTO is really needed to recover from a bursty data
> loss, even with SACK in use ([1] is a nice paper describing observed
> behavior in GPRS network). So if there happened to be an exceptionally
> long delay spike, but also RTOs caused by packet losses, the total
> performance (from the sender's perspective) could be worse with this
> response than with TCP that does not detect spurious timeouts, even in
> environment that has motivated much of the spurious RTO work. I don't
> know what could be appropriate way to limit K: just a fixed,
> configurable value, or by some adaptive method.

I hope the current version of the draft addresses this point better.

Basically, our feeling is that bounding K to some number is pointless.
Say we put some bound B on K.  Now, say we have a delay spike of 2*B and
hence we'd use B as the value of K.  What would that really do?  Well,
it would delay legitimate RTOs.  But, it would not prevent spurious RTOs
that we have observed.  So, it's really quite unattractive all the way
around. 

Rather than bounding K it seems that there could be a point whereby an
implementation might just decide that K should not be changed.  I.e., we
don't want to make K = 2*B and making it K > 4 and < 2*B doesn't really
solve anything.  So, the answer there is not to change K at all.  (Of
course, if we see another delay spike that makes K > 4 and say 0.5*B
then we could use 0.5*B to offer some protection.  In other words, we
have observed that while delay spikes are sometimes 2*B and the cost of
mitigating these is too high, we have also seen smaller delay spikes
that we are willing to mitigate.)

Does this make sense?

Thanks,
allman

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