From nobody Sun Mar 20 17:04:29 2022 Return-Path: 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 514013A15ED; Sun, 20 Mar 2022 17:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 DEcNEB1qSZd6; Sun, 20 Mar 2022 17:04:11 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 91AC83A15EC; Sun, 20 Mar 2022 17:04:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:From:Cc:References:To:Subject: MIME-Version:Date:Message-ID: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=KhgPFQCoycZd8JU8C4hRXmXzuUruVolpiFc1Ryq+Pr4=; b=tP5U4WKfBdkfSiFrshErgnK2bS WO5hqTxOjToG6f7xqhYbRJHlNN5q19eFhcZCYYHIYJXSGhq4+EdAefKRAwO8PiHOX+sc2h2NUXaUp 3JGfMbjZfBs42kXtgDd8CnhmkVhavmrSDaORfXdu8/oMN6t7xhqC9IIi/yf+OlYq3nPd5by5U052o qDaNv9mFsku/Gim/D/ptyXH9Q6ZKt45gagE5iolVs/QdSbdf4+M3nZpcvUXwZ8LeGGK/25g/TylYX uBMzHp1peUGcJvyBRROJy0aKeBkxJWHeeiSLrss9+8LT3C8VFuBB8dpiqEF3FM7d2mh+/LatQk+if B+x5APUQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:50698 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nW5Wq-0004mG-QP; Mon, 21 Mar 2022 00:04:07 +0000 Content-Type: multipart/alternative; boundary="------------bPjNhlAM2LiTOevzmZWnR1r2" Message-ID: Date: Mon, 21 Mar 2022 00:04:04 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB To: Gorry Fairhurst References: Cc: "tsvwg@ietf.org" , tcpm IETF list From: Bob Briscoe In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] AccECN and updating RFC3449 X-BeenThere: tcpm@ietf.org 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: Mon, 21 Mar 2022 00:04:17 -0000 This is a multi-part message in MIME format. --------------bPjNhlAM2LiTOevzmZWnR1r2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Gorry, [cc'ing tcpm, given this is a tcpm draft] On 18/03/2022 19:31, Gorry Fairhurst wrote: > I have problems with the proposal for AccECN update to RFC3449. > > I found the ID complex spec to read, as it digs into multiple ways to > perform accurate ECN reporting, so when thinking about ACK > modification in a router, it's not easy too see what level of > transport processing is desirable. > > The method seems robust to loss, and ought to work with tunnels, etc. > > RFC3449 references RFC3168, which is itself updated. That seems oK to me. > > The latest rev. of the AccECN ID says in the abstract: > “The document also specifies the >    treatment of this updated TCP wire protocol by middleboxes, updating >    BCP 69 with respect to ACK filtering.” > > - I did not find a specification in 3.3.3 that looked like it would be > accepted into a BCP. That concerns me, so I'm directing my comment to > the requirements line, [BB] The original requirement regarding ACK filtering and ECN in RFC3449 was equally brief and high level: Appropriate treatment is also needed to preserve correct operation of ECN feedback (carried in the TCP header) [RFC3168]. Section 3.3.3 in the AccECN draft says the two minimal normative things that are surely necessary now that there will be two different ECN schemes using the same TCP header bits: A node that implements ACK filtering (aka. thinning or coalescing) SHOULD determine if an ACK is part of a connection using AccECN and SHOULD then preserve the correct operation of AccECN feedback. > and the following the two bullets: > > Bullet 1: > > This bullet motivates that routers seek to detect the use of accurate > ECN ("SHOULD determine if an ACK is part of a connection using > AccECN"), I think that needs to be qualified if kept. For me there > seems a possibility that this add more "complexity" to the ACK > processing, and therefore less predictable behaviour. This does not > feel like it is a "SHOULD" or is necessarily good practice. [BB] Presumably you agree that it is reasonable that ACK filtering ought to preserve the correct operation of ECN (as in RFC3449). And now that AccECN introduces a second different ECN feedback scheme using the same bits, surely you agree that ACK filtering ought to preserve correct operation of AccECN as well. If you think that an ACK filtering function can (or at least might) preserve the operation of both schemes without knowing which one each packet is using, then yes we don't need bullet #1. Is this what you're saying? We also need to bear in mind the subsequent para, which says that AccECN hosts have to be robust in the face of *existing* ACK filtering, whether or not it preserves the correct operation of AccECN. I believe what we're trying to do here is ensure that ACK filtering preserves its intention to *improve* performance - then merely functioning would be OK, but not the goal. > > Bullet 2: > > This second bullet raises a concern that was motivated in 2.3, and I > think that the text is useful as it warns, but does not propose. I > think it is correct and proper to indicate that the use of AccECN can > be impacted by routers that manipulate/thin ACKs. 2.3 talks about what Data Receivers need to watch for. It doesn't mention middleboxes. 3.3 collects together all the items of interest to middlebox implementers. This second bullet merely explains the concern. I thought that's what you want. > > At the moment, the related requirement as written is: > "SHOULD then preserve the correct operation of AccECN feedback.", > which I didn't see specified.I think it could also be useful perhaps > as you do to speculate that it might be beneficial to update these > routers, however the current text does not seem to be best current > practice, at best it seems too vague.  For instance: I'm not clear > what the text advocates when a queue of accurate ECN ACKs build at an > intermediary. [BB]  I don't really understand what you want us to do. You seem to want us to be less specific and more specific. You seem to want us to warn not propose (which I agree with), and that's what I thought we were doing. But then you seem to want us to say how an ACK filter should actually work with AccECN, which is surely beyond the scope of this draft. Can you perhaps hint towards the text you are hoping for? > > In summary, I think I don't understand the need for the Updates line, > and I do not see a BCP-style recommendation emerging yet. Maybe we > just need experience and a short draft could write down what the IETF > recommendation is, if there is finally a need for a change? [BB] It's problematic, because RFC3449 is a BCP, but it only says the bare minimum (quoted above) about ACK filtering with ECN. However, that bare minimum needs to be updated because ensuring the correct operation of RFC3168 is no longer enough. Given RFC3449 doesn't use normative language, where the AccECN draft updates RFC3449, I would be happy not to use normative language either. But I think it would still have to update RFC3449. Wouldn't it? [BB] Finally, during this conversation I've noticed the following two lines. If they remain after we complete this conversation, I suggest they are clarified as below:           ACE field wrap is of less concern if           packets also carry the AccECN TCP Option           ACE field wrap *might**be* of less concern if           packets also carry the AccECN TCP Option. *However, ** **                   note that logic to read an AccECN TCP Option is optional to ** **                   implement (albeit recommended   see Section 3.2.3).  So one end ** **                   writing an AccECN TCP Option into a packet does not necessarily ** **                   imply that the other end will read it.* Bob > > Gorry > > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------bPjNhlAM2LiTOevzmZWnR1r2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Gorry, [cc'ing tcpm, given this is a tcpm draft]

On 18/03/2022 19:31, Gorry Fairhurst wrote:
I have problems with the proposal for AccECN update to RFC3449.

I found the ID complex spec to read, as it digs into multiple ways to perform accurate ECN reporting, so when thinking about ACK modification in a router, it's not easy too see what level of transport processing is desirable.

The method seems robust to loss, and ought to work with tunnels, etc.

RFC3449 references RFC3168, which is itself updated. That seems oK to me.

The latest rev. of the AccECN ID says in the abstract:
“The document also specifies the
   treatment of this updated TCP wire protocol by middleboxes, updating
   BCP 69 with respect to ACK filtering.”

- I did not find a specification in 3.3.3 that looked like it would be accepted into a BCP. That concerns me, so I'm directing my comment to the requirements line,

[BB] The original requirement regarding ACK filtering and ECN in RFC3449 was equally brief and high level:
   Appropriate treatment is also needed to preserve correct operation of
   ECN feedback (carried in the TCP header) [RFC3168].

 Section 3.3.3 in the AccECN draft says the two minimal normative things that are surely necessary now that there will be two different ECN schemes using the same TCP header bits:
   A node that implements ACK filtering (aka. thinning or coalescing)
   SHOULD determine if an ACK is part of a connection using AccECN and
   SHOULD then preserve the correct operation of AccECN feedback.

and the following the two bullets:

Bullet 1:

This bullet motivates that routers seek to detect the use of accurate ECN ("SHOULD determine if an ACK is part of a connection using AccECN"), I think that needs to be qualified if kept. For me there seems a possibility that this add more "complexity" to the ACK processing, and therefore less predictable behaviour. This does not feel like it is a "SHOULD" or is necessarily good practice.

[BB] Presumably you agree that it is reasonable that ACK filtering ought to preserve the correct operation of ECN (as in RFC3449). And now that AccECN introduces a second different ECN feedback scheme using the same bits, surely you agree that ACK filtering ought to preserve correct operation of AccECN as well.

If you think that an ACK filtering function can (or at least might) preserve the operation of both schemes without knowing which one each packet is using, then yes we don't need bullet #1. Is this what you're saying?

We also need to bear in mind the subsequent para, which says that AccECN hosts have to be robust in the face of *existing* ACK filtering, whether or not it preserves the correct operation of AccECN. I believe what we're trying to do here is ensure that ACK filtering preserves its intention to *improve* performance - then merely functioning would be OK, but not the goal.


Bullet 2:

This second bullet raises a concern that was motivated in 2.3, and I think that the text is useful as it warns, but does not propose. I think it is correct and proper to indicate that the use of AccECN can be impacted by routers that manipulate/thin ACKs.

2.3 talks about what Data Receivers need to watch for. It doesn't mention middleboxes.
3.3 collects together all the items of interest to middlebox implementers. This second bullet merely explains the concern. I thought that's what you want.


At the moment, the related requirement as written is:
"SHOULD then preserve the correct operation of AccECN feedback.", which I didn't see specified.I think it could also be useful perhaps as you do to speculate that it might be beneficial to update these routers, however the current text does not seem to be best current practice, at best it seems too vague.  For instance: I'm not clear what the text advocates when a queue of accurate ECN ACKs build at an intermediary.

[BB]  I don't really understand what you want us to do. You seem to want us to be less specific and more specific.
You seem to want us to warn not propose (which I agree with), and that's what I thought we were doing.
But then you seem to want us to say how an ACK filter should actually work with AccECN, which is surely beyond the scope of this draft.

Can you perhaps hint towards the text you are hoping for?


In summary, I think I don't understand the need for the Updates line, and I do not see a BCP-style recommendation emerging yet. Maybe we just need experience and a short draft could write down what the IETF recommendation is, if there is finally a need for a change?

[BB] It's problematic, because RFC3449 is a BCP, but it only says the bare minimum (quoted above) about ACK filtering with ECN. However, that bare minimum needs to be updated because ensuring the correct operation of RFC3168 is no longer enough.

Given RFC3449 doesn't use normative language, where the AccECN draft updates RFC3449, I would be happy not to use normative language either.
But I think it would still have to update RFC3449. Wouldn't it?

[BB] Finally, during this conversation I've noticed the following two lines. If they remain after we complete this conversation, I suggest they are clarified as below:

          ACE field wrap is of less concern if 
          packets also carry the AccECN TCP Option

          ACE field wrap might be of less concern if
          packets also carry the AccECN TCP Option.  However,   
                   note that logic to read an AccECN TCP Option is optional to   
                   implement (albeit recommended   see Section 3.2.3).  So one end   
                   writing an AccECN TCP Option into a packet does not necessarily   
                   imply that the other end will read it.

Bob


Gorry 



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------bPjNhlAM2LiTOevzmZWnR1r2--