Re: Question on draft-seemann-quic-accurate-ack-ecn-00

Vidhi Goel <vidhi_goel@apple.com> Thu, 14 March 2024 22:16 UTC

Return-Path: <vidhi_goel@apple.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A230C14F6A4 for <quic@ietfa.amsl.com>; Thu, 14 Mar 2024 15:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=apple.com
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 Qxf_xolF3kjD for <quic@ietfa.amsl.com>; Thu, 14 Mar 2024 15:16:50 -0700 (PDT)
Received: from ma-mailsvcp-mx-lapp02.apple.com (ma-mailsvcp-mx-lapp02.apple.com [17.32.222.23]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 337F9C14F5EB for <quic@ietf.org>; Thu, 14 Mar 2024 15:16:50 -0700 (PDT)
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma-mailsvcp-mx-lapp02.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SAC00H93Z808C30@ma-mailsvcp-mx-lapp02.apple.com> for quic@ietf.org; Thu, 14 Mar 2024 15:16:49 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-14_13,2024-03-13_01,2023-05-22_02
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=avAPZ7qCflWnDzMSr9VIBJXFkyx6c7mfBvPq/XTG0r0=; b=Cjp/mGlKVUjtLDWagDEphWuGMMsVpCAC8DLxjta73aP9wV+zcrZCrIEtUDSPhGMap1Tf wXRlg6nKCJ5nCx5MqGn0fnccGq5vCkMwgiQ3Uxj/yDUQCmDSC4uq0LTCAsqyDa1fvwbU kAIk1mYAn3rSOJHJ8n7WfsDYay86Ok04FFMsyfxvRyVfj+lywoR8YWe++wCN+4ROHG97 3rEiMhrdUd4/rp95m1EHYz5kET4ANKteEmC0UO65eTUhEa8iF9uU0aLdaecZRHmpX7qp cmXSTBzYUzHgf0FlJ01akRMA9U1WO8XXaaLEq1xFd0Y8Ksy01P408ZQvClM987Z7ZdKY EQ==
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0SAC004L7Z80P131@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 14 Mar 2024 15:16:48 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0SAC00I00Z7I6D00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 14 Mar 2024 15:16:48 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 7d3c09f53fcaad642c1d7cf77adc786e
X-Va-E-CD: ae04be2b7c0e3b0d4834ac98898174ad
X-Va-R-CD: 59be55625c2119360971adbc1eededbe
X-Va-ID: 1d53ab62-f056-41db-b8c8-b1b7003c2a75
X-Va-CD: 0
X-V-A:
X-V-T-CD: 7d3c09f53fcaad642c1d7cf77adc786e
X-V-E-CD: ae04be2b7c0e3b0d4834ac98898174ad
X-V-R-CD: 59be55625c2119360971adbc1eededbe
X-V-ID: b1b625c7-ce86-4b6b-b144-3c5c0bcdacff
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-14_13,2024-03-13_01,2023-05-22_02
Received: from smtpclient.apple (vmini.scv.apple.com [17.192.154.43]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0SAC00SEGZ7Z6800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 14 Mar 2024 15:16:48 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <E3F91BCF-226D-47B9-B9C9-D963A27C19E5@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_962134E6-E205-4FEA-A317-14860F8CF1A8"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.700.2\))
Subject: Re: Question on draft-seemann-quic-accurate-ack-ecn-00
Date: Thu, 14 Mar 2024 15:16:37 -0700
In-reply-to: <AM8PR07MB8137AF3A08688D32BABC73C9C2292@AM8PR07MB8137.eurprd07.prod.outlook.com>
Cc: "martenseemann@gmail.com" <martenseemann@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
References: <AM8PR07MB8137AF3A08688D32BABC73C9C2292@AM8PR07MB8137.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3731.700.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/S2T7xqtRjoCaF-7P91peH4I10G4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2024 22:16:54 -0000

Hello Ingemar,

Having been implemented Prague myself, this is mainly to get more accuracy around doing increase for non-marked bytes during congestion avoidance. Currently, we have no way of knowing that as we only know that some N packets were not CE marked but we don’t know which ones. 

If you see the example that I added in the draft, with the change proposed, an implementor can exactly know which packet was received with which code point. This way,  one can map the packet to packet size at the sender and accurately  compute non CE marked bytes. This is quite useful to do more accurate increase for cwnd to stay closer to the link capacity without building any excessive queues.

It may look like the change has subtle impact but with a large number of flows sharing the bottleneck, it definitely has impact on how tightly we control the increase in queuing delay.

Happy to discuss this during IETF.


Thanks,
Vidhi

> On Mar 14, 2024, at 7:21 AM, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Marten + others
>  
> I read through the draft
> https://datatracker.ietf.org/doc/draft-seemann-quic-accurate-ack-ecn/
>  
> Given that this adds more complexity than the default ECN counters, could you elaborate a bit more around which partcular cases where it would be beneficial with your proposed ECN feedback?
>  
> Regards
> /Ingemar
> =================================
> Ingemar Johansson  M.Sc.
> Master Researcher
>  
> Ericsson AB
> GFTL ER Networks RNS Protocol & E2E Perf
> Labratoriegränd 11
> 977 53, Luleå, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.johansson@ericsson.com <mailto:ingemar.s.johansson@ericsson.com>
> www.ericsson.com <http://www.ericsson.com/>
>  
>          The right to be ridiculous is
>               something I hold dear...
>                               U2
> =================================