Re: [tcpm] A question about PRR/loss recovery

Neal Cardwell <ncardwell@google.com> Fri, 16 April 2021 19:44 UTC

Return-Path: <ncardwell@google.com>
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 942A13A32A1 for <tcpm@ietfa.amsl.com>; Fri, 16 Apr 2021 12:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 GePhgmh8aa-N for <tcpm@ietfa.amsl.com>; Fri, 16 Apr 2021 12:44:18 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 D213F3A329C for <tcpm@ietf.org>; Fri, 16 Apr 2021 12:44:17 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id p9so1087185vkf.10 for <tcpm@ietf.org>; Fri, 16 Apr 2021 12:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ffbA7EEy0jm4TCwjUl4uQyhLllVI6WQ5wfqB9XLMz0k=; b=ZziPZVrxGj6uBB9bvZ0My5/vD8P0f0DImlvSTfaAY9lTGj9LE8rliAN2CLckUQAJJy sR8VpTRMN7gw3GxUsxC9Jan8+BGtOYpXVwCIBzvNnJNQe641SpXDvKPsuHWfwG5lmzfu +6VRBOWQ/JlalfaxFdp0gRy2Jjw5Hk+Q5yGnyQ2zsl5fYgZTb0maIwJLt29FWeDTwdOS D8X1xvvDkJjMr5aWedHjWZCzhvGs91SIzlSilwSLxGuDDqZR4g8EB6Um/12v2XZexGso uTW973ZEWagG4j9IY8NzGAtAxD0p83Xg7YHxZeL5erdx5vwrhV4IJ9SclgFNkVg74INR 1ybA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ffbA7EEy0jm4TCwjUl4uQyhLllVI6WQ5wfqB9XLMz0k=; b=QjbfiayyUpOFDnJkay1LIPEDAAg/l1yPaAJ8FZYUMgBZRrKA84B+vT86YfrjksAwZh /qjb1gDU1j2zNCqIgqoQk5I4IFig0of8x642MN3EPx00gta6crRa6YLZaD9u3RnAl1+c 4LHL/wN2XE5xCg0IyESMwrcAvzkP9DdEMSmTO+E5Aa3lZFgiS/L4wyEChnsE2AbiZsEA rS9nz73hLE6iKFF8PLz8IqMppTAxwAP0oijjAxGHXKMIofzOvDsCxhjGwmXcbyDwlLei bqzqEVJYqyhse704fXgCSMu2Jkuwz4CG7JInmE1yUP9DI51w27Lbbb74NfrweIMxRfsR x+uA==
X-Gm-Message-State: AOAM532ccWbxwXSxK5BvWNh1/yCclShzQi6k4WgXDquNHym17AiqgWMz lw9WfXEnv0Gqquaa8t/eRtwG4bOj+o6W3pI8Vkkavg==
X-Google-Smtp-Source: ABdhPJyV53VcajHbwgGRQCweOi2v0Fo7CiqfnRoTnBwESTBiTobb14tQs9m49RsviAi+2++7ZhfFRGwFZdb1o/DdcOU=
X-Received: by 2002:a1f:1fcc:: with SMTP id f195mr8759200vkf.17.1618602254922; Fri, 16 Apr 2021 12:44:14 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR00MB08779B864962711A2F35F2F4C34C9@MN2PR00MB0877.namprd00.prod.outlook.com>
In-Reply-To: <MN2PR00MB08779B864962711A2F35F2F4C34C9@MN2PR00MB0877.namprd00.prod.outlook.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Fri, 16 Apr 2021 15:43:58 -0400
Message-ID: <CADVnQy=2rC4N84DDMV-Ovo8v_wNZ3i_fd4AkXzCYY2W0cdcqnQ@mail.gmail.com>
To: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Yuchung Cheng <ycheng@google.com>, Matt Mathis <mattmathis@google.com>, Nandita Dukkipati <nanditad@google.com>
Content-Type: multipart/alternative; boundary="00000000000070929e05c01c34b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/qSOSJ9NaIlgbp9CR2ACBAV2Tq8k>
Subject: Re: [tcpm] A question about PRR/loss recovery
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: Fri, 16 Apr 2021 19:44:23 -0000

On Fri, Apr 16, 2021 at 3:08 PM Yi Huang <huanyi=
40microsoft.com@dmarc.ietf.org> wrote:

> Hi tcpm and PRR authors,
>
>
>
> We are revisiting PRR implementation in Windows and I noticed there might
> be a problem in our implementation (and it is actually not specific to PRR).
>
>
>
> PRR algorithm computes a sndcnt on each ACK during loss recovery and thus
> use it to accurately regulate bytes in-flight.
>
>
>
> In the RFC (6937 or bis), I see this statement and note “local” and
> “response to each ACK”.
>
>    We introduce a local variable "sndcnt", which indicates exactly how
>
>    many bytes should be sent in response to each ACK.
>
>
>
> In Windows’ TCP implementation, new data can be also sent out inline
> during loss recovery from app send context (app calling send()) and they
> are not regulated by sndcnt/PRR. Instead, we just check if CWND allows us
> to send in this case. So, effectively, we use two variables controlling the
> number of bytes in flight during loss recovery, i.e. sndcnt and CWND. It
> apparently seems a bad behavior because it ignores PRR’s sendcnt but I just
> want to double check with the PRR authors and the community.
>
>
Thanks for the note.

I believe that approach runs contrary to the intent of the PRR
spec/algorithm.

Implicit in the end of the algorithm in
https://tools.ietf.org/html/rfc6937#section-3 is the following line (in
pseudocode):

  cwnd = pipe + sndcnt

That is what the Linux TCP implementation of the PRR algorithm does. That
way there is only one variable (cwnd) controlling the number of bytes in
flight during loss recovery. Effectively, this allows the PRR algorithm
decision to persist, in case there is no data available to send at the
instant the ACK arrives.

Perhaps the update to the PRR RFC can make this explicit?

best,
neal