[tcpm] RFC3448 & AccECN

"Gorry (erg)" <gorry@erg.abdn.ac.uk> Sat, 19 March 2022 19:48 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4B35F3A0F00 for <tcpm@ietfa.amsl.com>; Sat, 19 Mar 2022 12:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id D8Qq_97no36p for <tcpm@ietfa.amsl.com>; Sat, 19 Mar 2022 12:48:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk []) by ietfa.amsl.com (Postfix) with ESMTP id A7FA13A0ED3 for <tcpm@ietf.org>; Sat, 19 Mar 2022 12:48:02 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8870.meeting.ietf.org []) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B8A2F1B000A6 for <tcpm@ietf.org>; Sat, 19 Mar 2022 19:47:56 +0000 (GMT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Sat, 19 Mar 2022 20:47:55 +0100
Message-Id: <11DAED43-B1D9-45E0-9DAC-AC28F5EF9AEB@erg.abdn.ac.uk>
To: tcpm IETF list <tcpm@ietf.org>
X-Mailer: iPhone Mail (19C63)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/TS2V21z0OhplQwA0OjX8bCnOTYU>
Subject: [tcpm] RFC3448 & AccECN
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: Sat, 19 Mar 2022 19:48:08 -0000

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, 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.

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.

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.

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?