IETF Logo Mail Archive

Re: [tcpm] Milestones changed for tcpm WG

Joe Touch <touch@strayalpha.com> Tue, 04 May 2021 04:48 UTC

Return-Path: <touch@strayalpha.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 304763A245D; Mon, 3 May 2021 21:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.387
X-Spam-Level:
X-Spam-Status: No, score=0.387 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 kJQG7Cf8VGXL; Mon, 3 May 2021 21:48:04 -0700 (PDT)
Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655523A2456; Mon, 3 May 2021 21:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Date:Cc:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To: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=etK2tQE35SnF3DWHL7DQABxkPYxM3pAIlo2GsMUEJMQ=; b=xrWPDFR94UYU0S6+UmQdUAYGnV scMMAOM7UW2n7rV7Vom6GcAhoX78talpYjfiDUtfOM3mlMOdTIQF3udYr1OOzSXGn0rP6zZvbKbcT Pv0rlYX109t5XdwNY0HaTm3HpIJ7IQ2vLZM7a8XTJobgrEa3BhIyslnzE6+w2JeqzkEHF8SmlTrTL Va08LvMb/joZJY6AH8k9VNZHQfMdwigqrvYZ235TjVJFvZ43PQHoRkUw/tML4743vRzyS24BEaU3a LTuCPVGRuA6AN4IAbxvGhwLDXuLMUIURsaG3ea9kVn8V8nCob2v33dkVGsS+LAkEstAj0egrEMmMx 63guE/RA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49925 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <touch@strayalpha.com>) id 1ldmyU-000WLz-Mn; Tue, 04 May 2021 00:48:03 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail-73EE55E0-0B72-4A9A-A253-06DD9133A474"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CAAK044RYPFaZU+X0GHFJksjbP0ub2WTZnLzv1RPzE4O5tn9sOg@mail.gmail.com>
Cc: tcpm IETF list <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Date: Mon, 03 May 2021 21:47:58 -0700
Message-Id: <B5AB51EF-01FD-4050-89B5-38E32141A63A@strayalpha.com>
References: <CAAK044RYPFaZU+X0GHFJksjbP0ub2WTZnLzv1RPzE4O5tn9sOg@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
X-Mailer: iPad Mail (18E199)
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/4WzlUkbfhm2WZu7tVXyo0jtQxvE>
Subject: Re: [tcpm] Milestones changed for tcpm WG
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: Tue, 04 May 2021 04:48:09 -0000

Yoshi,

> On May 3, 2021, at 9:10 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
> 
> Hi Joe,
> 
> On Mon, May 3, 2021 at 11:06 AM Joseph Touch <touch@strayalpha.com> wrote:
>> Hi, Yoshi,
>> 
>>> On May 2, 2021, at 11:31 PM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>>> 
>>> Hi Joe,
>>> 
>>> Thanks for bringing this up again. 
>>> In my understanding, there was no clear consensus on the interactions with TSO yet. Or, have we settled?
>> 
>> I don’t understand what “consensus” would mean.
>> 
>> TSO isn’t a standard; it’s an implementation, i.e., which ought to follow the TCP standards.
>> 
>> Nothing we’re doing deviates from how standards-compliant implementations handle options. However, if an implementation incorrectly ignores unknown options, then it would could be problematic for this approach, as well as others.
>> 
>>> I thought you'll update the draft for this. 
>> 
>> I’m not sure what to say about this issue - do you want me to point out the issue with TSO sometimes causing problems because it’s out of spec?
>> 
>> If so, I can do that.
>> 
> 
> 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

>  
> Thanks,
> --
> Yoshi
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email