[tcpm] Re: draft-ietf-tcpm-rfc4138bis-00

[Pasi Sarolahti <[e-mail]>]

Hi Alfred and all,

Note to the list: we have got some off-list feedback regarding the F- 
RTO draft and the companion evaluation document presented in Chicago,  
available at:
http://tools.ietf.org/html/draft-ietf-tcpm-rfc4138bis-00
http://tools.ietf.org/html/draft-kojo-tcpm-frto-eval-00

In attempt to spin up some discussion on the mailing list, with his  
permission, I'm cc:ing my reply to Alfred to TCPM.

To summarize the discussion below, the only open technical question  
we have is whether to include the SACK variant of F-RTO from RFC 4138  
in the Proposed Standard, or whether to leave it out. The latter was  
our choice for -00 version. We'd like to hear people's opinions on  
this, or anything else regarding the above two drafts. We don't have  
many to-do items on our list, so unless there are any comments/issues  
coming up, I believe the next version of rfc4138bis should be quite  
close to final on our behalf.

More comments below...

On Sep 11, 2007, at 19:15, ext Alfred HÎnes wrote:

>>> I have no technical objections to the draft, including the
>>> streamlining performed, leaving out SCTP and SACK related topics.
>>
>> Thanks, good to know. There have been some opinions also for leaving
>> the SACK version in the draft, so this kind of feedback are useful
>> to see if there seems to be "rough consensus" on one way or another.
>> Personally I would be happy to leave the SACK version out.
>
> Hmmmm.
>
> F-RTO for SCTP should definitely be left out now, and be dealt
> with in a separate document if it turns out to be required.
> (Furthermore, doing so avoids any possible conflicts regarding
> which WG should deal with the documents, TCPM vs. TSVWG.  :-) )

Thanks for the input. I think we agree.

> Since I do not have detailed knowledge regarding the degree of
> SACK support and actual use in the internet now, I admittedly
> just had followed your arguments.
>
> But, if it turns ot that SACK will gain, or already has gained,
> significant importance, it might indeed be reasonable to keep
> the SACK variant of F-RTO in 4138bis.  To this end, it might be
> useful to consider and evaluate the role of SACK for the evolution
> of other aspects of TCP (and other transport protocols); if it
> turns out, e.g., that SACK would be quite useful and important
> for the expected predominant response algoritms for F-RTO anyway,
> that should be taken as a firm indication that the SACK variant
> of F-RTO should be left in the document.

First, one note of clarification: a TCP that uses SACK can still use  
the basic version of F-RTO based on cumulative acknowledgements just  
fine. The SACK variant of F-RTO was intended to improve cases where  
duplicate ACKs (for reordering, for example) prevent detection of  
spurious RTO with the basic algorithm. To my understanding such cases  
are quite rare, so the additional benefit might not be too significant.

I have started to hesitate with my opinion on the SACK variant. We  
proposed dropping out the SACK variant from the 4138bis draft,  
because it seemed that it has not been as thoroughly analyzed as the  
basic F-RTO. Also, the SACK version of F-RTO has not been included in  
all implementations that have the basic version (for example Linux  
distribution has had only the basic version). However, after I  
mentioned about dropping SACK in the Chicago presentation, it turned  
out in the hallway discussions that there are implementations of the  
SACK variant in real use. So if it seems that the consensus is for  
keeping the SACK variant in 4138bis, that's fine with me as well. I'd  
be happy to hear more comments on this!

> For instance:
> The RFCs produced by the PILC WG have presented the analysis of,
> and recommendations for, the use of TCP in particular environments
> with particular properties and/or restrictions.  These RFCs should
> be reconsidered (I do not have the time now to do that - even by
> just scratching at the surface) to find out whether there are
> important scenarios that might be particular candidates for gaining
> high benefit from F-RTO (plus a matching response algorithm) which
> already have requirements or recommendations for the use of SACK.

Hmmm... Sorry, I'm not sure if I understood what you mean here. PILC  
documents recommend SACK for the lossy links, but I don't see clear  
relationship to F-RTO. Some of the documents discuss a bit about  
spurious timeouts, but SACK is not mentioned in that scope.

>>> Yet, overall IMHO the arguments in favor of F-RTO are now repeated
>>> too often in the text - in sections 1. Introduction, 2.2 Discussion,
>>> and 4. Evaluation ...
>>
>> Ok, I'll try to read these sections with this in mind. It might show
>> from the text that in the first round for the Experimental RFC we
>> needed to more work justifying F-RTO, which probably is not needed
>> so much anymore.
>
> After my second pass over the evaluation draft, I also have
> reconsidered that topic as well.
>
> Is it intended to have the latter be published as a companion,
> Informational RFC, to the 4138bis, or shall it just serve WG
> internal purposes (and IESG/IAB requirements -- not precisely
> constrained in BCP 133 with regard to the form of publication)?
> In particular in the former case, IMHO there should be a clear split
> between the specification document (4138bis) and the eval document,
> leaving *most* of the background and justification information and
> evaluation report material out from the specs and replacing it by
> pointers to the eval document, as far as BCP 133 admits.

I'm not sure about the fate of the frto-eval draft. It's purpose was  
to document the gained experience since the Experimental RFC 4138, to  
support the process of advancing the document to Proposed Standard.  
It could have been published in some different format (technical  
report, etc.), but we thought that an Internet-Draft would be quite  
IETF'ish. I think rfc4138bis should be readable on its own, without  
references to the eval document.

Thanks for the comments!

- Pasi


> Kind regards,
>   Alfred.
>
>
> P.S.:  Since I'm not on the TCPM (and TSVWG) lists, I thoughtlessly
> have hereby written another personal communication that might
> indeed be of interest for the group(s).  Thus, if it deems useful
> to you, please forward this message, or parts of it, to the list.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- 
> Phys.  |
> | Gerlinger Strasse 12   |  Phone: [phone], Fax:  
> -18         |
> | D-71254  Ditzingen     |  E-Mail:  ah@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>


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