Re: [tcpm] Milestones changed for tcpm WG

Joseph Touch <touch@strayalpha.com> Fri, 07 May 2021 16:50 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 DCDF63A2937; Fri, 7 May 2021 09:50:33 -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, RCVD_IN_DNSWL_BLOCKED=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 nrInlkxqoJIV; Fri, 7 May 2021 09:50:29 -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 51A873A296A; Fri, 7 May 2021 09:49:35 -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: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=tL1Roa4XJZ9x200JrHdQ+GoUm+Hmeev1xqCQSV8+s1Q=; b=qAIgso97tBLFsmEEsQHxZTaYMM bf/dRjSXIKueRWvCF8UFFaOzDVnVrY+2kPL9PhfJJGOk9KqveSOp+uWNPzxawqGTZcp1iJwTzElDS uKfgqSeTzd4f6JyC+6mlLPHYxMMpPdK2WblXHEj4t5uftXl+DzuG1qK1XNXogX8sA5JGW/NDR0hMe dUOjLQAoVjsmnj1KN1kOyXRwqhurz/db1JHB95ivkuPOnUoIBbqt2RzbiwxJ6oB/Yuyc/Od3hY0sA qJ9EgO/JMdPAHOwLu2uj0Jnd2Hqe7fmZUxy6zXNPCkYzrV/f+okcDZsaiHQhBY9g9lcYA0lcwkgop LZEQWSCw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56799 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1lf3fM-00461g-SK; Fri, 07 May 2021 12:49:34 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_E9B3921E-44D2-44AB-9687-501FF36ED688"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <b6ef493662594409877ca870686d9942@hs-esslingen.de>
Date: Fri, 7 May 2021 09:49:27 -0700
Cc: tcpm IETF list <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
Message-Id: <B6D4277F-3FF7-4481-A7DE-7B08D84DDE5F@strayalpha.com>
References: <CAAK044RYPFaZU+X0GHFJksjbP0ub2WTZnLzv1RPzE4O5tn9sOg@mail.gmail.com> <B5AB51EF-01FD-4050-89B5-38E32141A63A@strayalpha.com> <2e6e1552fcc442fb8464668a649ce9e8@hs-esslingen.de> <DB679A55-CD0B-4975-A585-12F76736318C@strayalpha.com> <b6ef493662594409877ca870686d9942@hs-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
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/WkVV0VP1M7h99bXxtM-8UFAhZoc>
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: Fri, 07 May 2021 16:50:34 -0000

Hi, Michael,

> On May 5, 2021, at 1:57 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> Hi Joe,
>  
> Adding more explicit text would improve the document.
>  
> And I suggest avoiding a discussion whether certain offloading mechanisms indeed follow the TCP specification, or not. Offloading seems to be a widely used technology. It is simply not our (i.e., the IETF’s) job to make judgement calls about design decisions of implementers.

Although I completely agree, but not calling out such flaws as errors opens the door to them later leaking into BCPs, “X considered harmful/fragile”, or even standards revision.

The point is that TSO is supposed to follow TCP specs, not the other way around. TSO is not a TCP spec.

> IMHO it is just sufficient to clearly describe in the EDO specification any known issues and potential mitigation strategies.

We also need to remember that “mitigation” includes indicating where errors occur and fixing them.

I’ll put in some text and we can debate it ;-)

Joe

>  
> Michael
>  
>  
>  
> From: Joseph Touch <touch@strayalpha.com> 
> Sent: Tuesday, May 4, 2021 10:27 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>om>; tcpm IETF list <tcpm@ietf.org>rg>; tcpm-chairs <tcpm-chairs@ietf.org>
> Subject: Re: [tcpm] Milestones changed for tcpm WG
>  
> Hi, Michael,
>  
> Below, yes - the text could be more clear.
>  
> I think what might best be said, in short, would be:
>  
> - some TSOs (like some middle boxes, though a separate issue) may not deal with this option properly (like any unknown option)
> - we have a method to detect that but, like all protocols, don’t anticipate using it all the time just to detect implementations that don’t follow the specs
>  
> So yes, the text could be revised (and will be). I think that’s a little different from a WG consensus call on whether to endorse misbehaving TSOs as something we should either endorse or design against in the default case.
>  
> Joe
> 
> 
> On May 4, 2021, at 12:20 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de <mailto:Michael.Scharf@hs-esslingen.de>> wrote:
>  
> Hi Joe,
>  
> As far as I can see, the relevant section in draft-ietf-tcpm-tcp-edo-10 is:
>  
>    Implementers need to be careful about the potential for offload
>    support interfering with this option. The EDO data needs to be
>    passed to the protocol stack as part of the option space, not
>    integrated with the user segment, to allow the offload to
>    independently determine user data segment boundaries and combine
>    them correctly with the extended option data. Some legacy hardware
>    receive offload engines may present challenges in this regard, and
>    may be incompatible with EDO where they incorrectly attempt to
>    process segments with unknown options. Such offload engines are part
>    of the protocol stack and updated accordingly. Issues with incorrect
>    resegmentation by an offload engine can be detected in the same way
>    as middlebox tampering.
>  
> In that paragraph, as non-native speaker, I don’t understand the sentence “Such offload engines are part of the protocol stack and updated accordingly.”
>  
> Maybe I miss something, but if there are potential issues with offloading, that could be described more explicitly and more clearly. In that case, more warning signs could be put in place at more prominent places in the document, too.
>  
> Personally, I would not be surprised if certain ways of offloading were more common than middlebox tampering. Well, I don’t know. Anyway, if that was true, a discussion regarding offloading might actually be more important than middlebox tempering.
>  
> Just as a random data point, if I were an implementer, I would probably expect a dedicated section regarding offloading, or something like that. And I would probably _not_ use the term “middlebox” when searching in the Web for material related to TSO… 
>  
> My 2 cents
>  
> Michael
>  
>  
>  
> From: Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> 
> Sent: Tuesday, May 4, 2021 6:48 AM
> To: Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>>
> Cc: tcpm IETF list <tcpm@ietf.org <mailto:tcpm@ietf.org>>; tcpm-chairs <tcpm-chairs@ietf.org <mailto:tcpm-chairs@ietf.org>>
> Subject: Re: [tcpm] Milestones changed for tcpm WG
>  
> Yoshi,
> 
> 
> 
> On May 3, 2021, at 9:10 PM, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto:nsd.ietf@gmail.com>> wrote:
> 
> 
> Hi Joe,
>  
> On Mon, May 3, 2021 at 11:06 AM Joseph Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
> Hi, Yoshi,
> 
> 
> 
> On May 2, 2021, at 11:31 PM, Yoshifumi Nishida <nsd.ietf@gmail.com <mailto: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 <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
>  
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>