Re: [tcpm] Linux doesn’t implement RFC3465

Mark Allman <mallman@icir.org> Thu, 29 July 2021 12:41 UTC

Return-Path: <mallman@icsi.berkeley.edu>
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 EEBB63A2180 for <tcpm@ietfa.amsl.com>; Thu, 29 Jul 2021 05:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cORPm7zDv8v2 for <tcpm@ietfa.amsl.com>; Thu, 29 Jul 2021 05:41:39 -0700 (PDT)
Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A023A217B for <tcpm@ietf.org>; Thu, 29 Jul 2021 05:41:38 -0700 (PDT)
Received: by mail-oo1-f42.google.com with SMTP id o17-20020a4a64110000b0290263e1ba7ff9so1541243ooc.2 for <tcpm@ietf.org>; Thu, 29 Jul 2021 05:41:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=/AUx2N6AlQufL1Oh57kHPnhRN6V/oLoJorq43SXm+Ds=; b=tVDQLuaJhhWRRIRBQgmRCIbZ+GW/TeFaIFh9HsW7BFKtg2uRumne5VnwOEDIshdNjX fc6xfyvm8cP/8URg3yZrFvne4xT9+HTB/5jFlisiGlthOacP6L9V7cRiZ/w3FUGxz5u/ d+agicQnBI5cP6/70BGwFBIMUMIZGWUKjOFiIwfanMRBwQ+/PuLlWTs7AWtea6HjWOm/ ZeZ52uIeuqBVZRkZxq42YVNKPzT4QxTdkgEykfP9yec+T8Bjq2td4EdskuVVprvAWQqc nAbQqr/FNuyZIfxSfp0D90KFjtbL2e/vKYZpKaRhTd4YcEw3qLndsS1IC6lDWANQLE3X YyVw==
X-Gm-Message-State: AOAM531ygcaITElTNFnzDNn1C2z2Mr6iS8XwUWtOT2HQj6GOtiSeIYwp OztmViQ4xw92PevEZczYLyL4sQ==
X-Google-Smtp-Source: ABdhPJyd4Vzd9dOjyrT9GbTwIZFxfHzKfZ4/3rGaaJL0iEMRDgVol/txW+obZc99GchH0j8Q7VdR1Q==
X-Received: by 2002:a4a:da0f:: with SMTP id e15mr2836020oou.53.1627562497935; Thu, 29 Jul 2021 05:41:37 -0700 (PDT)
Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id i18sm569274oik.3.2021.07.29.05.41.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 05:41:37 -0700 (PDT)
From: "Mark Allman" <mallman@icir.org>
To: "Vidhi Goel" <vidhi_goel@apple.com>
Cc: Extensions <tcpm@ietf.org>, "Neal Cardwell" <ncardwell@google.com>
Date: Thu, 29 Jul 2021 08:41:24 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <E150D881-4AB3-4AEA-BE0C-1D4B47B2C531@icir.org>
In-Reply-To: <DF5EF1C7-0940-478A-9518-62185A79A288@apple.com>
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <CADVnQynkBxTdapXN0rWOuWO3KXQ2qb6x=xhB35XrMU38JkX2DQ@mail.gmail.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <DF5EF1C7-0940-478A-9518-62185A79A288@apple.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_B688FF40-D4CD-45C9-8BB7-62DA46BFCCF5_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/HIrxbS4nVwZwkFtzZK1SCkoogoU>
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
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: Thu, 29 Jul 2021 12:41:44 -0000

I just inhaled notes from Vidhi, Yuchung and Neal.  And, I am trying
to page the recesses of my brain back in ... :-)

I have a few thoughts ...

  - I sort of agree with Yuchung & Neal in spirit, if not
    particulars.

  - During the initial slow start phase I think it'd be fine to say
    either:

    (a) If you use some sort of burst mitigator/pacing, an
        implementation can increase cwnd by the number of bytes
        ACKed on each ACK (i.e., no L).

    (b) If there is no burst mitigation then we have to figure out
        if L is still useful for this purpose and whether we want to
        retain it.  Seems like perhaps L=2 is sensible here.  L was
        never meant to be some general burst mitigator.  However,
        ABC clearly *can* aggravate bursting and so perhaps it makes
        sense to have it also try to limit the impact of the
        aggravation (in the absence of some general mechanism).

  - During slow starts that follow RTOs there is a general problem
    that just because the window slides by X bytes doesn't say
    anything about the *network*, as that sliding can happen because
    much of the data was likely queued for the application on the
    receiver.  So, e.g., you can RTO and send one packet and get an
    ACK back that slides the window 10 packets.  That doesn't mean
    10 packets left.  It means one packet left the network and nine
    packets are eligible to be sent to the application.  So, it is
    not OK to set the cwnd to 1+10 = 11 packets in response to this
    ACK.  Here L should exist and be 1.

  - It is possible that someone could work out a SACK-based scheme
    to try to figure out how much of the ACK is data leaving the
    network and how much of it was data sitting in the buffer at the
    receiver.  And, if we could do that then we could say "L=1
    unless you use a fancy algorithm".  My guess, however, is this
    is likely a fool's errand for two reasons.  First, on an RTO the
    scoreboard is supposed to be cleared and while SACK information
    will slowly get built back up we lose a bunch of state that we
    could perhaps use to differentiate between "left network" and
    "left buffer".  Second, receivers are supposed to ACK out of
    order segments and those that fill in holes immediately.  If
    they do that, it means that every ACK received actually does
    convey one segment leaving the network and therefore L=1 is
    correct and even an accurate SACK-based algorithm wouldn't let
    one increase cwnd more than L=1 would.  (One caveat here is I am
    not sure how this thinking would play with the offload stuff.)

allman