Subject: [tcpm] Re: frto

From: Reiner Ludwig <[email-masked]>
Date: Tue, 13 Apr 2004 11:02:19 +0200

I have finally read the -01 draft, and here are some comments. Editing stuff I will sent directly to the authors.

Main comments
-------------

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

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

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

- The SACK-version of F-RTO seems vague and is hard to follow. For example, ...
  * in step 2) you say "If duplicate ACKs arrive, ... but stay in step 2." What does 'staying in step 2' mean: continue waiting for ACKs or proceed to step 2a)?
  * "..., it MAY follow one of the [many] options presented in Section 2."
  * there are no explanations / motivations presented for the steps of SACK-verion of the algorithm. 

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

Minor comments
--------------

- 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 ...'. Mixing everything up causes unnecessary double meanings, and potential confusion, especially for those who are not so familiar with the TCP-lingu. 

- Aligning terminology across RFCs: 
  * "first unacknowledged segment" > "oldest outstanding segment" 
  * "delay peak" > "delay spike"
  * "high_data" > "RecoveryPoint" [RFC3517]
  * "new ACK" > "acceptable ACK" [RFC793]

- 2nd para in Intro: you should add that standard TCP usually breaks packet conservation after a spurious timeout.

- I suggest to structure Section 2 into subsections:
  * one that contains nothing but the pure algorithm
  * a subsection for each step where you explain and motivate
  * a subsection for general discussion: the last three paragraphs of the 
    current Section 2.

- Your definition of a spurious timeout is not very precise. We had a lengthy discussion on this related to the Eifel detection algorithm, remember :-) This has resulted in the definition we give in Section 2 of RFC3522 (see 2nd para + the note).

- Algorithm 2a: 
  "If ... it [the ACK] is acknowleding a sequence number equal to (or above) the value of send_high [...] continue by retransmitting unacknowledged data in slow start" Really?
I suggest to simply say "If the acknowledgement ... in step 1, the TCP sender MUST exit the F-RTO algorithm." (same in the the SACK version)

- Algorithm 2b:
  "If the acknowledgement ... of send_high, ..." > "Else, ..."

- Algorithm 3a:
How about setting CWND to the loss window (LW) + 2 * MSS. Or instead of (2 * MSS) the ABC equivalent of that?

- You talk about "bugfix" and RFC2582. This should be made consistent with the update to RFC2582.

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

I hope this helps.

///Reiner

At 16:17 12.03.2004, Mark Allman wrote:

>Hello!
>
>As discussed at the meeting last week we'd like to encourage folks to
>read and comment on the F-RTO draft: draft-ietf-tsvwg-tcp-frto-01.txt.
>Based on the feedback we've received so far it seems like all the large
>issues have been working out of this draft and it is near ready to be
>forwarded.  We'd like folks to read the document and send any remaining
>issues to the list.
>
>Thanks!
>
>allman
>
>
>--
>Mark Allman -- ICIR -- http://www.icir.org/mallman/

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

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 13 Apr 2004 16:44:22 +0300

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

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

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Apr 2004 12:04:46 -0400

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

Might I suggest a middle ground.... It seems as if Reiner's assertion is
that the language about SCTP is vague -- indicating that maybe the SCTP
stuff is not as well thought out.  And, it seems that Pasi is saying
that the SCTP stuff has been thought about.  So, will a simple cleanup
of the language (making the SCTP language less speculative) fix things
here? 

> 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 think I agree with Pasi.  Although, at the same time, while not
recommending or endorsing the Eifel response, I think that noting that
it is the only one currently specified within the RFC series is a good
idea (and, for all practical purposes, would constitute an implicit
recommendation, I think).

allman