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

On Sep 26, 2007, at 16:52, ext Ilpo Järvinen wrote:

>> 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).
>
> ...That's only partially valid because since 2.6.22 Linux has included
> both versions (though both off by default). Its SACK version includes
> features discussed in 4138's Appendix B. From 2.6.24 onward it will
> enable SACK version by default.

So I had outdated information. Thanks for keeping us updated!

Ok, we were too hasty in removing the SACK variant from the draft.  
The feedback so far, on and off the mailing list, seem to be in favor  
of keeping it. We'll add it back for the next version.

> Quite clearly using SACK blocks improves FRTO's accuracy in  
> detection as
> they are rather strong indication what really arrived. However, it  
> adds
> some challenges to aggressive response usage because then lying in  
> SACK
> blocks should also be addressed in Security Considerations,  
> especially as
> "because the sender will have an incorrect state, it cannot retransmit
> the segment that has never reached the receiver" does not hold like it
> does with SND.UNA. Yet, as long as FRTO is accompanied with a  
> conservative
> response, I don't see how the receiver could have meaningful  
> benefits from
> lying, whereas unnecessary retransmissions are more accurately  
> mitigated.

This reminds me of another issue mentioned in the Chicago meeting  
that might deserve discussion: what should we say about the response  
in rfc4138bis? The current draft refers to the Eifel Response and to  
draft-allman-rto-backoff as possible response algorithms, but also  
says that if neither of these is implemented, the TCP sender should  
respond conservatively to spurious timeout, applying the TCP  
congestion control specification. I wonder if people prefer more  
definite words here about the response, or is it just enough to refer  
to the known choices, as we now have done. What you say above seems  
to indicate that at least with SACK we might want to prefer a  
conservative response.

- Pasi

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm