Re: [tcpm] Re: frto

[Pasi Sarolahti <[e-mail]>]

Reiner,

Thanks for the comments. My responses below.

On Tue, 2004-04-13 at 12:02, ext Reiner Ludwig wrote:

> - For SCTP, the specification of the F-RTO algorithm seems too vague.
> We have a paper in one of the upcoming CCR journals where we developed
> a version of Eifel for SCTP. Although SCTP is very similar to TCP in
> many ways, we still found a number of subtleties that required special
> treatment. So, I'm not convinced when you simply write "... the
> algorithms and other discussion should be applicable also to SCTP."
> Thus, I would like to see a more detailed specification + discussion
> for SCTP, or else the SCTP stuff removed.

Based on the current understanding I have on F-RTO & SCTP, I disagree.
The draft discusses the known issues that make F-RTO with SCTP different
from TCP, based on what was pointed out on the tsvwg mailing list about
a year ago. Unless there are some more specific issues that are
problematic for F-RTO with SCTP, I would like to keep the section.

> - You explicitly allow F-RTO to be triggered during an ongoing loss
> recovery, i.e., upon multiple timeouts for the same segment or upon a
> timeout during fast recovery. Are you sure this works? What if RFC3517
> is triggered upon the 3rd DUPACK, the fast retransmit is sent + other
> segments are retransmitted, and the sender times out again? The fast
> retransmit could be lost or excessively delayed, or ... 
> I haven't thought this through, but it seems to be a tricky situation.
> If you can't be 100 percent sure F-RTO works in all these cases, I
> suggest to only allow the triggering of F-RTO at the very beginning of
> loss recovery. The same comment applies to the SACK-version of F-RTO.

Yep, we also noticed that SACK loss recovery and F-RTO is a bit hairy
combination. That's why we disallowed F-RTO if earlier SACK fast
recovery is underway. This was already said for SACK-based algorithm,
and the next version of the draft says the same also on the basic
algorithm side, should someone apply the basic version with SACK TCP.
With Reno/NewReno there should not be problems since they make only one
retransmission per RTT.

> - Algorithm 2b:
> "If the TCP sender does not have any new data to send, the TCP sender
> SHOULD transmit a segment from the retransmission queue."
> You don't say whether it should transmit one or two segments, and you
> also don't specify which segments. Later in this section you discuss
> various options. Some of those you do not encourage and some you leave
> unqualified. I think this is too vague. Implementors will have a hard
> time to make a choice. I suggest you settle for one option that gets
> specified and recommended. You can still discuss in some section why
> you have settled for that option and not for others - if you think
> that adds to the doc.

We have had also some other comments on this, and it will be changed in
the next version. It'll be about the way you outline above.

> - The SACK-version of F-RTO seems vague and is hard to follow. For
> example, ...
[...]

Agree. We have worked on the SACK section recently and it'll be
hopefully clearer in the next version.

> - Section 4 
>   * Why don't you explicitly recommend using F-RTO with the Eifel
> response algorithm (a soon to be RFC) instead of outlining
> alternatives that have been proposed outside of the IETF? 
>   * Why do you consider the response to spurious timeouts a subject of
> further research when we have already reached consensus in the IETF
> about how to do this response?

Yes, there has been rough consensus for taking Eifel Response for
Experimental RFC. However, since other kinds of responses have also been
discussed in the IETF mailing lists and by some papers, we wanted to
keep options open for those, and for any possible future work, too. I
thought this was the main reason for doing the separation in to
detection and response algorithms in the first place, right? Of course,
since Eifel Response is (soon) the only response-related RFC so far,
it'll be the likely option chosen by most.

> Minor comments
> --------------
[...]

I generally acknowledge and agree with these, although...

> - The 'RTO' is the retransmission timeout value. It's a value not an
> event. If you talk about a timeout (event), I think, you should say
> 'timeout' or '... when the retransmission timer expires ...'.

Looking at the recent RFCs from tsvwg, this doesn't seem to be the
common practice. However, I do agree that the terminology should be as
clear as possible. We'll try to keep our focus on this.

> - You say that one benefit of F-RTO is that it allows the sender to
> take RTT sample sooner, and that this leads to larger RTOs. I don't
> think so because without timestamps and without F-RTO the RTO will
> stay backed off, i.e., rather large, until a previously unsent segment
> is sent and acknowledged due to Karn's algorithm [RFC2988].

The draft just mentions about the side-effect of not retransmitting
delayed segments has on the RTT estimator and thus on the RTO value.
Well, I don't have too much against dropping or modifying the paragraph
if folks don't like it, although I still would like to keep the current
note we have there.

> I hope this helps.

Thanks, these are helpful indeed.

- Pasi

-- 
http://www.iki.fi/pasi.sarolahti