From nobody Mon Aug 8 06:47:50 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 48009C14F721; Mon, 8 Aug 2022 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txDM9ZGCodAS; Mon, 8 Aug 2022 06:47:44 -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 01173C14CF11; Mon, 8 Aug 2022 06:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:Cc:From: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=K18TI9zLBD+p2d+jqajUgIjjUj+I9JlLG8mTPLaFZZ4=; b=A64jn9c+6mKnXC43sJ2YXkX9c4 IbRG9wt7gMNO5qb5pnfJJmPYd194uf4rAw+2prWLdNnCgkuJYxUdq3YVJzMX8zZGIN5YIeyZmd9zm vgcxp3MUFCHtpAHYLUKCHMH+2msMqAH88T5ay7nGzwCBsYIMM60JmBrcqcIO8rPaIVJwQhpnAqZC4 yXBLeyd0kkpeHDGV6wsyECOZ3OJ8E+5CLy9gyAZJRX0gHYnbluxMe46jkjQ2aAKhNfz/mfRClTnH4 fcorEMwIEVg+f7x/WQEtQoUq7Uc4UQKGfm4tIQdPXiRVY9T06+u2vC2zaqtI/G/kovXY+RDmfq8wi E4Wg9K9w==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:39678 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from ) id 1oL36c-0001Lc-20; Mon, 08 Aug 2022 14:47:41 +0100 Content-Type: multipart/alternative; boundary="------------OF5P8DMiinDTW4TCRFuNc6gu" Message-ID: Date: Mon, 8 Aug 2022 14:47:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-GB To: "Klatsky, Carl" , "tsvwg@ietf.org" References: From: Bob Briscoe Cc: tcpm IETF list 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] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id question X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.39 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, 08 Aug 2022 13:47:49 -0000 This is a multi-part message in MIME format. --------------OF5P8DMiinDTW4TCRFuNc6gu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Karl, See BB inline, [I've added tcpm to the distro] On 04/08/2022 16:54, Klatsky, Carl wrote: > > Hello tsvwg-ecn-l4s-id authors, > > Question on this part fron section 4.2 > >    TCP:  Support for the accurate ECN feedback requirements [RFC7560] > >       (such as that provided by AccECN [I-D.ietf-tcpm-accurate-ecn]) by > >       both ends is a prerequisite for scalable congestion control in > >       TCP.  Therefore, the presence of ECT(1) in the IP headers even in > >       one direction of a TCP connection will imply that both ends > >       support accurate ECN feedback. However, the converse does not > >       apply.  So even if both ends support AccECN, either of the two > >       ends can choose not to use a scalable congestion control, whatever > >       the other end's choice. > > I follow the comment about the converse case where both ends support > AccECN but decide not to use it. Is there ever a case where both ends > support AccECN and negotiate it per table 2 in tcpm-accuarte-ecn, yet > do not set ECT(1) in the IP header for some reason, but then will > respond if they see CE set on packets by the bottleneck link entity? > Trying to understand if this is possible, and if possible is it likely > to occur or just hypothetical.  Thanks. > [BB] This is perfectly possible, because the idea is that Accurate ECN TCP feedback (AccECN) provides a superset of both Accurate and Classic ECN feedback. Meaning, AccECN supports the same API to the feedback of a CE event as was there with RFC3168 ECN feedback. So, if both ends have an updated kernel that supports AccECN, and both ends have loaded a Classic (non-L4S) congestion control module (e.g. CUBIC) with ECN support, then they would negotiate to use AccECN at the TCP layer and both send ECT(0) packets at the IP layer. Then, if a CE arrived at the data receiver, it would feed it back using AccECN's ACE counter (and optionally the AccECN TCP options), and the data sender would detect an increase in the counter, so the CUBIC module would trigger CUBIC's window decrease and ignore all further increases to AccECN's counters for the next round trip. If AccECN became supported by default in some OSs, this could become a very likely case, at least while CUBIC is the default congestion control for most OSs. Another possible case would be that both ends support AccECN, one has an L4S CC module loaded (e.g. Prague) and the other has a Classic CC module loaded (e.g. CUBIC). Then the packets in one direction would all be set to ECT(1) while the data packet in the other direction would be set to ECT(0) while the TCP control packets (SYN, SYN-ACK, pure ACKs, retransmissions) would be zeroed to Not-ECT. I used to always include a diagram in the spare slides of every AccECN presentation explaining where it fits in the stack. But the last time I did was Nov'21 (see the last slide here): https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-more-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notification-01#page=12 This may or may not help! The introduction of the AccECN spec should also help. But if you can suggest any better ways of saying it, or any gaps in what it says, pls do. https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20 Cheers Bob > Regards, > > Carl Klatsky > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------OF5P8DMiinDTW4TCRFuNc6gu Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Karl, See BB inline, [I've added tcpm to the distro]

On 04/08/2022 16:54, Klatsky, Carl wrote:

Hello tsvwg-ecn-l4s-id authors,

 

Question on this part fron section 4.2

 

   TCP:  Support for the accurate ECN feedback requirements [RFC7560]

      (such as that provided by AccECN [I-D.ietf-tcpm-accurate-ecn]) by

      both ends is a prerequisite for scalable congestion control in

      TCP.  Therefore, the presence of ECT(1) in the IP headers even in

      one direction of a TCP connection will imply that both ends

      support accurate ECN feedback.  However, the converse does not

      apply.  So even if both ends support AccECN, either of the two

      ends can choose not to use a scalable congestion control, whatever

      the other end's choice.

 

I follow the comment about the converse case where both ends support AccECN but decide not to use it.  Is there ever a case where both ends support AccECN and negotiate it per table 2 in tcpm-accuarte-ecn, yet do not set ECT(1) in the IP header for some reason, but then will respond if they see CE set on packets by the bottleneck link entity?  Trying to understand if this is possible, and if possible is it likely to occur or just hypothetical.  Thanks.


[BB] This is perfectly possible, because the idea is that Accurate ECN TCP feedback (AccECN) provides a superset of both Accurate and Classic ECN feedback. Meaning, AccECN supports the same API to the feedback of a CE event as was there with RFC3168 ECN feedback.

So, if both ends have an updated kernel that supports AccECN, and both ends have loaded a Classic (non-L4S) congestion control module (e.g. CUBIC) with ECN support, then they would negotiate to use AccECN at the TCP layer and both send ECT(0) packets at the IP layer. Then, if a CE arrived at the data receiver, it would feed it back using AccECN's ACE counter (and optionally the AccECN TCP options), and the data sender would detect an increase in the counter, so the CUBIC module would trigger CUBIC's window decrease and ignore all further increases to AccECN's counters for the next round trip.

If AccECN became supported by default in some OSs, this could become a very likely case, at least while CUBIC is the default congestion control for most OSs.

Another possible case would be that both ends support AccECN, one has an L4S CC module loaded (e.g. Prague) and the other has a Classic CC module loaded (e.g. CUBIC). Then the packets in one direction would all be set to ECT(1) while the data packet in the other direction would be set to ECT(0) while the TCP control packets (SYN, SYN-ACK, pure ACKs, retransmissions) would be zeroed to Not-ECT.

I used to always include a diagram in the spare slides of every AccECN presentation explaining where it fits in the stack. But the last time I did was Nov'21 (see the last slide here):
    https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-more-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notification-01#page=12
This may or may not help!

The introduction of the AccECN spec should also help. But if you can suggest any better ways of saying it, or any gaps in what it says, pls do.
    https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20

Cheers


Bob

 

Regards,

Carl Klatsky

 


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