Re: [tcpm] Milestones changed for tcpm WG

Joseph Touch <> Tue, 04 May 2021 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E40BB3A1278; Tue, 4 May 2021 09:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.386
X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.484, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7f2OWnF2lt5z; Tue, 4 May 2021 09:59:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 478613A1272; Tue, 4 May 2021 09:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0RCJKiE8G44jI/vQPUOsKQHaslwmv9dmnYlRCZXWcNI=; b=4RydWm4O53zFyMSt/scpqHAHI fJavjgZppFjX5AIFRI1VOTjyCMOqqtyKVe4TeKaR1RNtwdIzcAjI+zF1UIZfh5ORvOXyv0gs6jfKK qiSPTLoWAyNl6q7tzI4DLRe8yMw0uCZvhK/0//Y8Q+87ofeWhLtZsyhWrUxjUnwC7lJ9fXX9B5gsb 7i/IVlwYLSZo3vWUtP/4QgCAulM7wfKtrYUU2N/Hm+n8q3d6rPt9SmnkIRWRYxUk7qU51+gizto18 Wqo/gafdVfsoz0wZkQhPDvBeRK2MbQ1eWqNxcx04QHK2odjDKjGGqKh/t8Mu9MD7QjKctuPmKWXW0 evD7q+0MQ==;
Received: from ([]:59754 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <>) id 1ldyO3-002MSW-Fq; Tue, 04 May 2021 12:59:12 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8FE0AA02-C48C-47BC-829E-401FB7C5EA0A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Tue, 4 May 2021 09:59:06 -0700
Cc: tcpm IETF list <>, tcpm-chairs <>
Message-Id: <>
References: <> <>
To: Yoshifumi Nishida <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] Milestones changed for tcpm WG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 May 2021 16:59:18 -0000

PS ---

> On May 3, 2021, at 9:47 PM, Joe Touch <> wrote:
> Yoshi,
>> ...
>> I think that would be helpful for the doc. But, I also think this doc should have a clear vision on the interaction with TSO beforehand. 
>> I think we should have a consensus on this point such as:
>> * EDO should not be used with TSO
>> * It's fine to use EDO with TSO in any circumstances.
>> * it's fine to use EDO with TSO under a certain conditions
>> * The draft does not need to specify anything for TSO as it's out of scope of the doc.
> These are not decisions for the WG. TSO isn’t a single thing; it’s a nickname for an implementation optimization.  Like all such optimizations, it’s always fine when it complies with specs and not when it doesn’t.
> I.e., everything stated above is equally possible if you replace “TSO” with “Linux”.
> It is out of scope for the WG to state anything about either (TSO or Linux) other then “it’s ok if it complies with secs and not when it doesn’t”.
> This is not the doc to point out that TSO (or any other implementation) sometimes breaks TCPs rules or that these, like all options, put TCP behavior at risk when that happens.
> Joe

FWIW, Sec 5.3 already indicates this.