Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

Yoshifumi Nishida <nsd.ietf@gmail.com> Wed, 09 February 2022 10:01 UTC

Return-Path: <nsd.ietf@gmail.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 D12D13A1375 for <tcpm@ietfa.amsl.com>; Wed, 9 Feb 2022 02:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 to6_r2iBvE4d for <tcpm@ietfa.amsl.com>; Wed, 9 Feb 2022 02:01:25 -0800 (PST)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 431FD3A127F for <tcpm@ietf.org>; Wed, 9 Feb 2022 02:01:25 -0800 (PST)
Received: by mail-qv1-xf34.google.com with SMTP id a28so1326008qvb.10 for <tcpm@ietf.org>; Wed, 09 Feb 2022 02:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q/Lv0bWb84NsoovzMiP+tLafQdybne4hUTPVoecexII=; b=nLdEKQmLIMyzDe1JNLL0uGIm18OjwSc8ZNz6Zlpeqb4GLgg+rm+0bNGD1mDT4KHdqn /KPyLt2uuX/WnTfN7+4sselunFnOK7P0WQ/FdTfwE7BEOr1Rj5eaRWf/rlQNeFWNje2X si75RnGTmgyWRTagy0pC81gM9WC6Zj0fBDBk0xPaf/bPnhagy3RJYQ8qp4kADljx5CMp Qeodc0QfOzjDF5Wu4xRRNSNsFJkHRg9XXSOLqGv2h1tEFUHjTtbgskaR8TUWswlIxN7C OlmLLuWgC99qgLuz9WS9eqjxdGO6LaklErakF9OAZjFsdvJwGwXu9UHgm8BFDdLfsblF Wn4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q/Lv0bWb84NsoovzMiP+tLafQdybne4hUTPVoecexII=; b=M1K70/PuvonqXocIw3wQL4e1MlEVUSxn83mPi/ED97aysk8T4ZMUKdPzZymWDCvtlV OLVFtzvlBzfBv6V0AC/5/kIagUlFvN/xhtFg6jtqJeeVZzTzkMH6r0P9PTj4cpZIgMfD QSqC00FE6in036Ze7R8i1xXl7ThQTqB1J6GpO8pDvuisM5HGFq1SJl+SIzZvOYe3oslD k14OzfWV9Hq5Ta6eg00kg6D5Lsxkac2+W3QDwLiopFY+Yq5Ai6wkIoIgnEmLVDAn5fqS YoYHlVAyeBeMqrL3sJWEUinMQf0LGYRogXmGHNKa1tOE0azRW8Jsj6+lmIYAJ+KdWVRC YoxQ==
X-Gm-Message-State: AOAM533mUYPMzJAol4PmQhw/AgOEsUEr4jy4klDqB8KsTkaNTrOx2Vbs vW7ns+bcHV9jBA8JDJIRWrDXEVySkEVfr1MA5lRFio0g
X-Google-Smtp-Source: ABdhPJwnzhSXUriLrMp6tIa9mkzamAm3B6qIYum+VrwBVuIOhIfC3u/B2KX9MkSVG/eNwPEgkHmkGha304eiqZnAeZY=
X-Received: by 2002:a05:6214:5294:: with SMTP id kj20mr890729qvb.111.1644400883465; Wed, 09 Feb 2022 02:01:23 -0800 (PST)
MIME-Version: 1.0
References: <164318837039.21788.17451980682651967578@ietfa.amsl.com> <EEA435EC-AAAC-4899-8E94-2D54EDE5F72E@eggert.org> <CAAK044S9HQXvfvgM6mBuvOWJPHtCaa6xo6CoP2r8Vq61tKaY5g@mail.gmail.com> <CAAK044R6B7HT0mdSDwHU=FhvN=A=M-8pxYb8wGfwxczwtCT-yw@mail.gmail.com> <492FC264-2D3C-4D3D-B7C2-D547593E4A7D@apple.com>
In-Reply-To: <492FC264-2D3C-4D3D-B7C2-D547593E4A7D@apple.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 9 Feb 2022 02:01:12 -0800
Message-ID: <CAAK044QXt8oHQ5qkqX3dKEuXKuXQTjiuRO=DKZkkrD7DeH4EOQ@mail.gmail.com>
To: Vidhi Goel <vidhi_goel@apple.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000086feb805d792ea1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/E8FSjFBCOZSDkrRrMY-kTLzXvkk>
Subject: Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis
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: Wed, 09 Feb 2022 10:01:30 -0000

Hi Vidhi,

Thanks for the comments.

On Mon, Feb 7, 2022 at 3:32 PM Vidhi Goel <vidhi_goel@apple.com> wrote:

> Thanks Yoshi for reviewing the draft.
>
> So, it seems one PS doc mentions not to use cwnd, while another PS doc
> mentions using cwnd is fine (with RFC7661).
>
> RFC5681 is conservative in its approach to use FlightSize and will result
> in very low throughput in scenarios when the congestion event occurs at the
> tail of send window (when flight size could be very small)
>

Yes. I agree.


>
> I am not sure which can cause this situation yet, but in any case, does
> this mean there is no concern on
> "some implementations may incidentally increase well beyond rwnd" in cubic?
> Is this because this is an old implementation bug or are there other
> reasons?
> I am wondering if we might want some clarification on this point.
>
> If an implementation uses RFC7661, there is no concern about increasing
> cwnd beyond rwnd as RFC7661 tracks bytes acknowledged in a RTT which means
> that `rwnd` check has already been performed.
> Usually cwnd doesn’t grow beyond rwnd  (ACK-clocking increases cwnd which
> means the sender already checked `rwnd` before sending out the data).
>
> But there could be implementations that may want to keep `rwnd` even
> smaller than initial `cwnd`. In those cases, RFC7661 would make the cwnd
> invalidated when the number of acknowledged bytes is much lower than the
> current cwnd.
>
> Do you have any suggestions on how to make it more clear?
>

I think it will be fine as long as the draft clarifies we can safely
override what's written in RFC5681 when we have some mechanisms such as
RFC7661.

> Also, I am wondering if we might want to use "MAY be used" here instead of
> "can be used"
>
> Yeah, we can make this change.
>

Thanks!
-- 
Yoshi


>
>
> Thanks,
> Vidhi
>
> On Feb 6, 2022, at 3:01 AM, Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>
> Hi,
> I just have one more comment on the draft.
> In RFC5681, it mentions in Section 3:
> ''
>
>    Implementation Note: An easy mistake to make is to simply use cwnd,
>    rather than FlightSize, which in some implementations may
>    incidentally increase well beyond rwnd.
>
> "
>
> while this draft mentions in Section 4.6:
> "
>
>    To avoid suboptimal performance with such applications,
>
>    the mechanisms described in [RFC7661 <https://datatracker.ietf.org/doc/html/rfc7661>] can be used to mitigate this
>    issue as it would allow using a value between _cwnd_ and
>    _flight_size_ to calculate the new _ssthresh_ in Figure 5.
>
> "
>
> So, it seems one PS doc mentions not to use cwnd, while another PS doc
> mentions using cwnd is fine (with RFC7661).
>
> I am not sure which can cause this situation yet, but in any case, does
> this mean there is no concern on
> "some implementations may incidentally increase well beyond rwnd" in cubic?
> Is this because this is an old implementation bug or are there other
> reasons?
> I am wondering if we might want some clarification on this point.
>
> Also, I am wondering if we might want to use "MAY be used" here instead of
> "can be used"
>
> Thanks,
> --
> Yoshi
>
> On Mon, Jan 31, 2022 at 11:43 PM Yoshifumi Nishida <nsd.ietf@gmail.com>
> wrote:
>
>> Hello,
>>
>> After some discussions among chairs, we decided to run the 2nd WGLC on
>> draft-ietf-tcpm-rfc8312bis in consideration of the importance of the draft.
>> We'll be grateful if you could send your feedback to the ML. The WGLC
>> runs until *Feb 11*.
>>
>> If interested, you can check in-depth past discussions in the following
>> URL.
>> https://github.com/NTAP/rfc8312bis/
>>
>> Thank you so much!
>> --
>> tcpm co-chairs
>>
>>
>> On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <lars@eggert.org> wrote:
>>
>>> Hi,
>>>
>>> this -06 version rolls in all the changes requested during (and after)
>>> WGLC ended.
>>>
>>> I'll leave it up to the chairs to decide if another WGLC is warranted or
>>> the document can progress as-is.
>>>
>>> Thanks,
>>> Lars
>>>
>>>
>>> > On 2022-1-26, at 11:12, internet-drafts@ietf.org wrote:
>>> >
>>> >
>>> > A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> > This draft is a work item of the TCP Maintenance and Minor Extensions
>>> WG of the IETF.
>>> >
>>> >        Title           : CUBIC for Fast and Long-Distance Networks
>>> >        Authors         : Lisong Xu
>>> >                          Sangtae Ha
>>> >                          Injong Rhee
>>> >                          Vidhi Goel
>>> >                          Lars Eggert
>>> >       Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
>>> >       Pages           : 35
>>> >       Date            : 2022-01-26
>>> >
>>> > Abstract:
>>> >   CUBIC is a standard TCP congestion control algorithm that uses a
>>> >   cubic function instead of a linear congestion window increase
>>> >   function to improve scalability and stability over fast and long-
>>> >   distance networks.  CUBIC has been adopted as the default TCP
>>> >   congestion control algorithm by the Linux, Windows, and Apple stacks.
>>> >
>>> >   This document updates the specification of CUBIC to include
>>> >   algorithmic improvements based on these implementations and recent
>>> >   academic work.  Based on the extensive deployment experience with
>>> >   CUBIC, it also moves the specification to the Standards Track,
>>> >   obsoleting RFC 8312.  This also requires updating RFC 5681, to allow
>>> >   for CUBIC's occasionally more aggressive sending behavior.
>>> >
>>> >
>>> > The IETF datatracker status page for this draft is:
>>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/
>>> >
>>> > There is also an HTML version available at:
>>> > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html
>>> >
>>> > A diff from the previous version is available at:
>>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06
>>> >
>>> >
>>> > Internet-Drafts are also available by rsync at rsync.ietf.org
>>> ::internet-drafts
>>> >
>>> >
>>> > _______________________________________________
>>> > tcpm mailing list
>>> > tcpm@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>