Re: [tcpm] 793bis: TCP Quiet Time

Fernando Gont <fgont@si6networks.com> Wed, 22 January 2020 18:57 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A82120805 for <tcpm@ietfa.amsl.com>; Wed, 22 Jan 2020 10:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXj1VncbZ4tk for <tcpm@ietfa.amsl.com>; Wed, 22 Jan 2020 10:57:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922E2120804 for <tcpm@ietf.org>; Wed, 22 Jan 2020 10:57:00 -0800 (PST)
Received: from [192.168.100.103] (unknown [186.183.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C7DCD82A3B; Wed, 22 Jan 2020 19:56:56 +0100 (CET)
To: Wesley Eddy <wes@mti-systems.com>, gorry@erg.abdn.ac.uk, "tcpm@ietf.org" <tcpm@ietf.org>
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <d6d45644-387a-6cee-8087-379c45f36e43@si6networks.com>
Date: Wed, 22 Jan 2020 15:54:37 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <5d11289c-0174-8a5e-7f47-b0110564a601@mti-systems.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/AZLdhRzjHLQV6EG8q6HK-Sy5xNE>
Subject: Re: [tcpm] 793bis: TCP Quiet Time
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 18:57:04 -0000

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: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492