Subject: [Tsvwg] F-RTO - open issues?

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 8 Oct 2002 17:57:39 +0300

Hi all,

I was encouraged by the tsvwg chairs to query for any open issues 
concerning draft-sarolahti-tsvwg-tcp-frto-01.txt describing a TCP RTO 
recovery algorithm for avoiding unnecessary retransmissions. 
Especially, I would like to know what do the people in this community 
feel about the following issues, since they have been under discussion 
in the past.

1. Is the present F-RTO approach of halving congestion window and 
ssthresh after spurious RTO ok? Alternatively, the congestion control 
parameters could be reverted to the earlier values after spurious RTO. 
There are two things in this: Firstly, I currently think that spurious 
RTO should be taken as a one kind of minor congestion event, although I 
believe there are different opinions about this. Secondly, loss of the 
retransmission triggered by spurious RTO is not noticed by the sender. 
Although this is a rare event, I think DSACK is the only 100% reliable 
method (known by me, at least) for reverting congestion control 
parameters without missing any possible packet loss.

2. F-RTO reverts to traditional RTO recovery (i.e. slow start 
retransmissions) after spurious RTO, if the segment following the one 
that triggered RTO is lost. We outline an optional SACK-based variant 
of F-RTO that can be used to avoid this, but I would like to know 
whether the relatively rare case of missing the spurious RTO is worth 
emphasizing the SACK-based variant of F-RTO, and the additional logic 
that follows from it.

3. If receiver window limits the forward transmission after spurious 
RTO, or if there are no new data to send, F-RTO reverts back to 
traditional RTO recovery. Of course, this is not the optimal behavior, 
but this was considered better than to wait without doing anything in 
order to keep the ACK clock running. In the draft we suggest an 
alternative method of transmitting data from the tail of the 
retransmission queue when the forward transmission is not possible, 
which would make it possible to proceed with the F-RTO logic. I would 
like to know what do people think about the latter alternative. 
Personally, I start to like it more and more.

Waiting for any feedback,
- Pasi
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Mark Allman <[email-masked]>
Date: Tue, 08 Oct 2002 14:36:56 -0400

Pasi-

I have just read through the most recent version of the draft.  I
think f-rto is a pretty slick idea and I'd like to see it move
forward.

My personal hit on your questions...

> ssthresh after spurious RTO ok?

My thinking...

  * I think it is OK.  The document recommends that DSACK could be
    used to completely revert the CC state, which is nice.

  * On the other hand, losing a spurious retransmit sounds like a
    rare enough event to me that I would be fine with reverting the
    CC state, as well.

  * But, if you fully revert the CC state then I think you need some
    mechanism to attempt to make sure that you do not continually to
    send bogus retransmits (i.e., increase the dupack thershold in
    fast retramsmit or do something to the RTO estimator).  So, in
    some sense by not allowing the total undo-ing of the CC state
    you are providing a disincentive from being extrememely
    aggressive in the RTO and then just backing out of it later.

  * So, I'd vote for leaving it the way it is.

> retransmissions) after spurious RTO, if the segment following the
> one that triggered RTO is lost. We outline an optional SACK-based
> variant of F-RTO that can be used to avoid this, but I would like
> to know whether the relatively rare case of missing the spurious
> RTO is worth emphasizing the SACK-based variant of F-RTO, and the
> additional logic that follows from it.

I think the document is fine.  The SACK version is better because it
has more information.  But,  don't think the reno version is awful.
The above seems like a corner case to me.

> 3. If receiver window limits the forward transmission after
> spurious RTO, or if there are no new data to send, F-RTO reverts
> back to traditional RTO recovery. Of course, this is not the
> optimal behavior, but this was considered better than to wait
> without doing anything in order to keep the ACK clock running. In
> the draft we suggest an alternative method of transmitting data
> from the tail of the retransmission queue when the forward
> transmission is not possible, which would make it possible to
> proceed with the F-RTO logic. I would like to know what do people
> think about the latter alternative.  Personally, I start to like
> it more and more.

Sending from the tail...  hm...

On the one hand, it seems to me that sending from the ACK point is
likely to be more useful (i.e., we have a partial ACK that *may*
indicate a missing segment vs. no information about the right side
of the window).  On the other hand, if nothing is lost sending from
the right side of the window may clue us in to this fact and allow
us to mitigate the spurious RTO.

My inclination is to go with the standard behavior because I don't
think I fully understand the tradeoffs in practice.  But, that is
just me.  (And, if you have some experimental results in this area
that would shed light on things then I would like to see them and
would like to reconsider.)

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 9 Oct 2002 16:19:53 +0300

Hi,

Thanks for the comments. I'll try to clarify the last point.

On Tuesday 08 October 2002 21:36, ext Mark Allman wrote:

> > back to traditional RTO recovery.
>

Yep, it sounds ugly in the first place, and sending from the tail of 
the retransmission queue would likely be an unnecessary retransmission. 
But it would be only one unnecessary retransmission, compared to having 
several of them, what could possibly be the case if there was a 
spurious RTO and the sender would retransmit in the traditional way. 
Something like this would be needed, because when sending from the ACK 
point, it would not be possible to detect if the original transmissions 
raised the cumulative acknowledgements.

However, I have not noticed the window limitation to be a significant 
problem for the F-RTO preformance so far. It's ok for me to leave this 
part of the text as it is now, i.e. suggest this as an option in case 
someone sees it necessary.

- Pasi

---

From: "Andrei Gurtov" <[email-masked]>
Date: Wed, 9 Oct 2002 17:05:31 +0300

Pasi-

The draft seems to be in a good shape, but below there are some things you
may
want to discuss more.

1. Clearly, F-RTO is not robust against packet reodering and packet
duplication. It seems fair if in your draft you pointed the reader to the
Eifel algorithm since that is an alternative that is robust in such cases.
In addition, the Eifel algorithm also works for spurious fast retransmits.

2. F-RTO does not improve standard TCP-Reno for application-limited
connections. It would be nice to inform the reader about that, especially
since such TCP connections are at least not uncommon. The same is true in
case the receiver window is shrunk after a timeout. Although, that seems
more rare, it would be good to point that out as well.

3. Have you thought about protection against malicious TCP receivers?

4. What should F-RTO do if the first acceptable ACK has the ECN-Echo flag
[RFC3168] set?

Also, more experimental results showing effects of different options
discussed in the draft would be helpful.

Andrei

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 9 Oct 2002 18:22:03 +0300

On Wednesday 09 October 2002 17:05, ext Andrei Gurtov wrote:

> duplication. It seems fair if in your draft you pointed the reader to
> the Eifel algorithm since that is an alternative that is robust in
> such cases. In addition, the Eifel algorithm also works for spurious
> fast retransmits.

I think this was said in Introduction for Eifel and in the end of 
Section 2 for F-RTO. 

> connections. It would be nice to inform the reader about that,
> especially since such TCP connections are at least not uncommon. The
> same is true in case the receiver window is shrunk after a timeout.
> Although, that seems more rare, it would be good to point that out as
> well.

There is some text about application limited case and receiver window 
in the end of page 5. A option for solving that case was suggested, and 
what I asked in the original mail was whether this is felt as a problem 
that should be emphasized more.

Currently I feel like this is not very bad a problem. Application 
limited case would quite often mean something like interactive usage or 
short transfers, in which case the window of outstanding segments is 
not typically very large, right? So there are not many segments to 
retransmit unnecessarily.

> 3. Have you thought about protection against malicious TCP receivers?

A receiver that sends malicious acks? I think any TCP sender is in 
problems in that case. Or is there something specific that concerns 
especially F-RTO?

> 4. What should F-RTO do if the first acceptable ACK has the ECN-Echo
> flag [RFC3168] set?

Good question. Without thinking it very thoroughly, it should be 
ignored because TCP sender should react to congestion at most once in a 
round-trip time, as said in RFC 3168. And currently F-RTO suggests to 
take spurious RTO as a congestion event.

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Wed, 09 Oct 2002 16:17:57 -0400

> 3. Have you thought about protection against malicious TCP

Yes!!!

Think of a receiver ACK splitting so the first half of the RTO-ed
segment is acknowledged in one ACK packet and the second half of the
RTO-ed segment is ACKed seperately in a second ACK packet.  That
fools your algorithm into thinking the retransmit was spurious and
not reducing cwnd as much (aiding the receiver).

Of course, that is pretty easy to fix -- i.e., make sure the first
ACK covers at least the number of bytes sent in the RTO-ed segment.

allman

---

From: Neil Spring <[email-masked]>
Date: Wed, 9 Oct 2002 13:21:26 -0700

> problems in that case. 

Not all TCP senders have problems with malicious receivers,
only those that trust all acks.

 http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-nonce-03.txt

is an allocation of a bit in the TCP header to allow the
receiver to prove it has received only un-ECN-marked
original (not re-) transmissions.

That internet draft, whose status I've forgotten though I
thought it was on the path toward submission to the IESG as
a Proposed Standard, was a result of some simple analysis
in:

 http://www.cs.ucsd.edu/~savage/papers/ICNP01.pdf

Although the ICNP paper describes the ECN case specifically,
its predecessor:

 http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf

describes a set of attacks a malicious receiver could employ
to subvert the sender's congestion control policy.  Not all
of these attacks work against robust senders.

enjoy,
-neil

---

From: Mark Allman <[email-masked]>
Date: Wed, 09 Oct 2002 22:58:38 -0400

> Yep, it sounds ugly in the first place, and sending from the tail
> of the retransmission queue would likely be an unnecessary
> retransmission.

So, to me this sounds awfully dicey -- i.e., we're going to send a
segment that we think is likely to be unneeded in order to *possibly
prevent* the transmission of some number of additional segments.
I think I'd need to see some data from the Internet before I would
be willing to buy that this was even something worth thinking
about (from a standards perspective).

allman

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

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 10 Oct 2002 11:12:32 +0300

> not reducing cwnd as much (aiding the receiver).

Now this is a good point! But I think it can be addressed with quite a 
little effort in the next version.

On the other hand, I don't see how could the receiver benefit in lying 
that the RTO was spurious if it wasn't. The sender would eventually 
need to go through recovery and reduce the congestion window again. 

[pause]

Hmm.. ok, the loss-of-a-retransmit case could be such if there was no 
burst avoidance implemented.

- Pasi

---

From: Mark Allman <[email-masked]>
Date: Thu, 10 Oct 2002 07:22:17 -0400

> On the other hand, I don't see how could the receiver benefit in
> lying that the RTO was spurious if it wasn't. 

If the RTO is considered good cwnd gets set to 1 segment.

If the RTO is considered spurious cwnd gets set to half its value
(according to F-RTO).

If the receiver can make the sender believe an RTO is spurious when
it is not the receiver can effectively keep the cwnd higher than the
sender would otherwise have kept it.

Would this lead to more loss (and, hence a further action by the
sender)?  Maybe.  Should we count on that?  Not in my opinion.

allman