Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03

Markku Kojo <kojo@cs.helsinki.fi> Thu, 02 September 2021 11:37 UTC

Return-Path: <kojo@cs.helsinki.fi>
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 6454C3A139A; Thu, 2 Sep 2021 04:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 rOChHz_q4lMR; Thu, 2 Sep 2021 04:37:44 -0700 (PDT)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA0F3A1398; Thu, 2 Sep 2021 04:37:43 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 02 Sep 2021 14:37:30 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=dHXdxrfR0XxrHjz6H fgfFlGrOdAF2W7Wny4Spnh9YEI=; b=C5LU1cUxNaUqpINy9Go3/4hwAaPEI1Ary ScIATp7NvOdOkdMEUOFZUJy66mc8WzMgY2TW6CD59W/8n67LV+r7zqt4Qv6v9wGU bY7HNY5SVUeDeYoXlyKaDIWucQL7MntBYVo8d9u/FDLLgWwpKdVy2dHuDHzeQEJU b+p8QX5BAs=
Received: from hp8x-60 (85-76-70-212-nat.elisa-mobile.fi [85.76.70.212]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 02 Sep 2021 14:37:30 +0300 id 00000000005A1C85.000000006130B77A.000020A1
Date: Thu, 2 Sep 2021 14:37:30 +0300 (EEST)
From: Markku Kojo <kojo@cs.helsinki.fi>
To: Lars Eggert <lars@eggert.org>
cc: Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>
In-Reply-To: <37C22CF4-611E-4663-B88B-02AED2AF630B@eggert.org>
Message-ID: <alpine.DEB.2.21.2109021410350.5845@hp8x-60.cs.helsinki.fi>
References: <CAAK044SjMmBnO8xdn2ogWMZTcecXoET1dmZqd6Dt3WzOUi359A@mail.gmail.com> <alpine.DEB.2.21.2108300740560.5845@hp8x-60.cs.helsinki.fi> <37C22CF4-611E-4663-B88B-02AED2AF630B@eggert.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/AFh2qzfRag7SwTfGG2Z2Bi9eUOk>
Subject: Re: [tcpm] Concluding WGLC for draft-ietf-tcpm-rfc8312bis-03
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, 02 Sep 2021 11:37:51 -0000

Hi Lars,

On Tue, 31 Aug 2021, Lars Eggert wrote:

> Hi Markku,
>
> On 2021-8-30, at 19:33, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org> wrote:
>> My sincere apologies as this comes very late in the process but I was not able to follow IETF mailing list at the time of WGLC nor during the recent weeks, and I couldn't attend IETF 111.
>
> it's always a bit disappointing to get a long review just when you
> thought you were done, but it will lead to a better document in the end
> - so thank you for your review!

I know. I was not intended to do a review but Yoshi's recent question and 
some discussions on the list that I catched up just recently aroused my 
interest. I was quite suprised myself on how many issues I found. Hope it 
is helpful.

One additionl thing that I didn't mention but what I found as I was 
trying to read the doc as if I didn't know anything about CUBIC: the 
algorithm specification is a bit scattered around the doc together with 
the discussion of the features. So, it is likely to require a reader to 
jump back and forth in the dc to get a full picture. It might be useful 
to gather the actual algorithm actions to be taken on occurance of 
differents events (congestion detected, enter congestion avoidance, a new 
ACK arrives, etc.) into a single place to have a compact and accurate 
description of when each of the algorithm actions exactly are taken and 
in which form. Most congestion control RFCs do it like this. To avoid any 
significant restructuring of the doc this might work best by adding a new 
section for it. Then the current Sec 4 may remain as a more detailed 
description and discussion/justification for various actions like it 
currently does. This is just my opinion on how to make the doc more easy 
to follow.

> We've created a bunch of GitHub issues based on the issues you
> identified, and will work on resolutions there. Do you have a GitHub ID
> we can use to tag you?

Done and sent to you.

While direct discussions via GitHub are sure useful, many of the issues 
may deserve discussion over the list as well, I believe.

Thanks,

/Markku

>> 1. ECN
>>
>> a) The draft modifies RFC 3168 when ECE arrives and would result
> ...
> https://github.com/NTAP/rfc8312bis/issues/83
>
>> b) RFC 8311 (sec 4.1) allows modifying the TCP-sender response to
> ...
> https://github.com/NTAP/rfc8312bis/issues/84
>
>> c) ABE (RFC 8511) is currently the only experimental RFC to modify
> ...
> https://github.com/NTAP/rfc8312bis/issues/85
>
>> 2. Slow-Start Overshoot w/ loss-based congestion conrol
> ...
> https://github.com/NTAP/rfc8312bis/issues/86
>
>> 3. RACK (and QUIC)
> ...
> https://github.com/NTAP/rfc8312bis/issues/87
>
>> 4. Fairness to AIMD congestion control
> ...
> https://github.com/NTAP/rfc8312bis/issues/88
>
>> 5. Contribution to buffer bloat and slower convergence due to
>>   larger decrease factor
> ...
> https://github.com/NTAP/rfc8312bis/issues/89
>
>> 6. Citing Experimental RFCs as if being a part of CUBIC
> ...
> https://github.com/NTAP/rfc8312bis/issues/90
>
>> 7. Discussion
> ...
> https://github.com/NTAP/rfc8312bis/issues/91
>
>> Sec 5.1
> ...
> https://github.com/NTAP/rfc8312bis/issues/92
>
>> Sec 5.3
> ...
> https://github.com/NTAP/rfc8312bis/issues/93
>
>> Sec 5.4
> ...
> https://github.com/NTAP/rfc8312bis/issues/94
>
>> Sec 5.5
> ...
> https://github.com/NTAP/rfc8312bis/issues/95
>
>> Sec 5.6
> ...
> https://github.com/NTAP/rfc8312bis/issues/96
>
>> Sec 5.8
> ...
> https://github.com/NTAP/rfc8312bis/issues/97
>
>> Sec 5.9
> ...
> https://github.com/NTAP/rfc8312bis/issues/98
>
>> 8. The draft says in the intro that CUBIC is to be regarded as *current standard* for TCP
> ...
> https://github.com/NTAP/rfc8312bis/issues/99
>
>> Misc comments:
>>
>> _epoch_start_: needs more accurate and consistent definition when the exactly the epoch
>
> ...
> https://github.com/NTAP/rfc8312bis/issues/100
>
>> In many occassions:
>> "(upon receiving) an ACK" -> "(upon receiving) a new ACK"
>
> https://github.com/NTAP/rfc8312bis/issues/101
>
>> On page 13:
> https://github.com/NTAP/rfc8312bis/issues/102
>
> Thanks,
> Lars
>
>