Re: [tcpm] A description of Linux pacing

Michael Welzl <michawe@ifi.uio.no> Fri, 22 March 2024 06:47 UTC

Return-Path: <michawe@ifi.uio.no>
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 06A49C14F5FE for <tcpm@ietfa.amsl.com>; Thu, 21 Mar 2024 23:47:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ifi.uio.no
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 IbsY7q8306jr for <tcpm@ietfa.amsl.com>; Thu, 21 Mar 2024 23:47:15 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 3B8DBC14F61E for <tcpm@ietf.org>; Thu, 21 Mar 2024 23:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2309; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From: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=20KDXd919IAKMKLbfG06NFfv4ommM6PbuRDn9oDI5Bk=; b=xzrPqmCnw6/NDqO8+/aTy2yfr3 OtMdp6k9twXav2zrJG60HsQpLB93rH3qKVFNUGkAhnaPoTrMLc6FlbDcBQgwi2vz3bbpLp0fTP89g klfeT1Jaej97YA3txrd8p/5RWnQQjw5vwOK3ynOksnFNOH5HNrIU0MZQvgycNGnCznGTKnyhPmo8X 1jN362PQiWQvS1SlUpUVHNPySUgKVVPMf8+bfLQv5JS76S5CM3KvM5eHuZLa/o0XPdL8mO9Qp1uCE w/292SEvX7H6FZMLpxm9rbFhig7iVx6R2CEHr82b9mKK8gZGiyZ1g//Xz7pQzkJzgk1pPMcA30Rau /kzKF2tw==;
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1rnYgB-00Fic8-0k; Fri, 22 Mar 2024 07:47:03 +0100
Received: from triforce.ifi.uio.no ([129.240.66.34] helo=smtpclient.apple) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1rnYg8-0004mf-1H; Fri, 22 Mar 2024 07:47:03 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <587F9123-886F-49B2-9145-B7BEBD0CDF73@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_70C7A834-E6DB-4160-9321-97EA5577C059"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Fri, 22 Mar 2024 07:46:49 +0100
In-Reply-To: <CAK6E8=e8zKtnKKinu3d81Wpk2gYRa8iPMO+Z9ynSd8PSP0Fp0A@mail.gmail.com>
Cc: Eric Dumazet <edumazet@google.com>, tcpm@ietf.org, iccrg@irtf.org
To: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>
References: <AE83F8F4-7D71-4034-93E7-365E1CD701F5@ifi.uio.no> <CAM4esxQg=MmBMJ-2dyWLX0HCy9yBCCaVBaWof31MFNBC-37ajQ@mail.gmail.com> <16FCCC7E-7F2E-453D-AD9B-BA6942C7B2F9@ifi.uio.no> <CAK6E8=e8zKtnKKinu3d81Wpk2gYRa8iPMO+Z9ynSd8PSP0Fp0A@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.400.31)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 129.240.66.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.66.34; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.2, required=5.0, autolearn=disabled, AWL=-0.151, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 449A50C9A367F69B46EF7F4D4718EC1C17C95413
X-UiOonly: DBFB78A6BF33A0575A035AEE619FDA763EF6E9C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/9l6XrZCqO646gOEzEPzQl5E5H0I>
Subject: Re: [tcpm] A description of Linux pacing
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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, 22 Mar 2024 06:47:21 -0000

This is useful indeed, many thanks for the pointer!  (*I* knew about it, but still).

This said, I found this reference, and others, to be too "high-level" for  my own purposes. I wanted to understand what I see at a finer detail, and I think that this is the kind of documentation that’s missing IMO.  (e.g., the initial burst limit of 10 (not IW, but hard-coded 10) packets, which took me by surprise, and will probably surprise others who were unaware; how micro bursts are used to implement a rate at a ~ 1ms granularity, with upper and lower bounds; the divergence from this for hosts that are less than 3ms away, …).

Cheers,
Michael



> On Mar 20, 2024, at 7:55 PM, Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org> wrote:
> 
> Neal and I have a short paper on Linux pacing, which integrates TSQ, and TSO autosizing. it has evolved over the years but the core design remains.
> https://netdevconf.info/1.2/papers/bbr-netdev-1.2.new.new.pdf
> 
> On Wed, Mar 20, 2024 at 12:42 AM Michael Welzl <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>> wrote:
>> Hi,
>> 
>> and thanks for your feedback!
>> 
>> I agree; I can write this up in time for the Vancouver IETF. As for documenting other implementations, I don’t know internals of any others… but I’m very willing to involve others in such an I-D - if any expert on a different OS is interested, get in touch!
>> 
>> Else, I could just make a start with this and see where it goes. It’s not much work, I can keep it short and simple.
>> 
>> Cheers,
>> Michael
>> 
>> 
>>> On 12 Mar 2024, at 23:08, Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>> wrote:
>>> 
>>> Speaking as an individual, it's a bummer we don't have a real RFC about pacing, this would be a decent Informational RFC for a way to do pacing, that is also a useful reference for how an important implementation does it.
>>> 
>>> Even more ambitious, one could document the approaches of several major implementations.
>>> 
>>> On Mon, Feb 19, 2024 at 6:06 AM Michael Welzl <michawe@ifi.uio.no <mailto:michawe@ifi.uio.no>> wrote:
>>>> Dear TCPM and ICCRG (I assume that there’s so much overlap with people in CCWG that it would just be spamming to send it there too?),
>>>> 
>>>> Over the last two weeks or so, I have put some effort into trying to understand how Linux pacing *really* works  (I had some descriptions that were somewhat high-level; I wanted to obtain a more precise lower-level understanding).
>>>> I wrote a document, just for myself, explaining what goes on in the code, as I can’t even try to follow the Linux kernel without taking notes.
>>>> 
>>>> After a first iteration, I shared it with the bufferbloat mailing list, in the hope of getting corrections.
>>>> I did!  Most notably (but not only), Neal Cardwell helped me a ton - and now the document should be quite thorough and hopefully correct.
>>>> 
>>>> While I only did this for myself and just asked the list for help, several people have in the meantime told me that this document is actually valuable for the community - and so I thought I should share it here, too.
>>>> It lives as a Google doc at this URL:
>>>> https://docs.google.com/document/d/1-uXnPDcVBKmg5krkG5wYBgaA2yLSFK_kZa7xGDWc7XU/edit?usp=sharing
>>>> 
>>>> Comments or fixes are very welcome!
>>>> Please feel free to forward this as you want.
>>>> 
>>>> I know that Google docs is not the format that we people here normally use  :-)   well, if someone thinks that it would indeed be useful to write this up as an I-D (probably skipping all the code details though), please let me know - I can do that, and I can also present it if there’s interest (but in Vancouver, not Brisbane).
>>>> 
>>>> Cheers,
>>>> Michael
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm