Re: [tcpm] 793bis: TCP Quiet Time

[Fernando Gont <[e-mail]>]

Hello, Wes,

On 18/12/19 18:33, Wesley Eddy wrote:
> I don't think I noticed anyone responding to Gorry's comment below, and 
> I haven't made any alterations in the 793bis draft with regard to this 
> (other than fixing some spelling mistakes).  I wanted to pull this into 
> its own thread in case other people have thoughts or would like to 
> discuss further what the quiet time concept's relevance is in 2020.

My response to Gorry in-line:


> 
> On 8/28/2019 11:39 AM, Gorry Fairhurst wrote:
>> OLD, Section: "   The TCP Quiet Time Concept"
>> - Found this section quite amusing. Is this concept widely implemented 
>> in stacks?

No.



>> - The examples given need updated, for instance one example starts "At 
>> 2 megabits/sec. it takes 4.5 hours to", clearly at 10 Gbps this line 
>> of thinking becomes problematic.
>> - There is an odd sentence that states:
>> "In the absence of knowledge
>>    about the sequence numbers used on a particular connection, the TCP
>>    specification recommends that the source delay for MSL seconds before
>>    emitting segments on the connection, to allow time for segments from
>>    the earlier connection incarnation to drain from the system."
>> - how would the "source" know the MSL rather than use the Internet 
>> default?

Unless I'm missing something, MSL implies the value specified in this 
spec. -- so there's no need to guess or "know" more than that.


(the real MSL is kind of tricky since, in theory, it is derived from the 
IPv4 Time to Live. You might know the TTL *you* use, but you probably 
won't know the TTL that other remote TCPs had employed. So, strictly 
speaking, in order to be safe you'd have to wait 255 seconds).



>> - To me, this section raises many questions about whether this is best 
>> current practice. 

AFAIK, it has never been a "best current practice". That said, you need 
the "quiet time concept" from a "correctness" point of view. -- 
otherwise the TCP SEQ takes care of old segments of the same incarnation 
of the connection, but not of old segments from a *previous* incarnation 
of the connection.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492