[tcpm] Re: frto

[Reiner Ludwig <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm