Re: [tcpm] Re: frto

[Mark Allman <[e-mail]>]

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

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? 

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


--
Mark Allman -- ICIR -- http://www.icir.org/mallman/