Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-request

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Mon, 21 March 2022 18:23 UTC

Return-Path: <carlesgo@entel.upc.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 404E33A1A91; Mon, 21 Mar 2022 11:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 NqqWNfLhzMfA; Mon, 21 Mar 2022 11:23:27 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 4A1303A1A93; Mon, 21 Mar 2022 11:23:26 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 22LIMdnv053919; Mon, 21 Mar 2022 19:22:39 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.40.6]) by entelserver.upc.edu (Postfix) with ESMTP id 5C2281D53C1; Mon, 21 Mar 2022 19:22:39 +0100 (CET)
Received: from 79.158.123.136 by webmail.entel.upc.edu with HTTP; Mon, 21 Mar 2022 19:24:00 +0100
Message-ID: <33196a9874acaef238f055399122b00b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <5d7f98b3-93b5-e37c-7a90-0b04e58aa482@bobbriscoe.net>
References: <7af3375e51f849c1ad934a758c30279e@hs-esslingen.de> <494ffff907b21034b43f3ca8151f79d1.squirrel@webmail.entel.upc.edu> <CCE0E8B4-3553-4F2D-A26A-54038CA09A0A@gmail.com> <07b348ce5ee706d1abffccd4878249f8.squirrel@webmail.entel.upc.edu> <5d7f98b3-93b5-e37c-7a90-0b04e58aa482@bobbriscoe.net>
Date: Mon, 21 Mar 2022 19:24:00 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: Bob Briscoe <in@bobbriscoe.net>
Cc: Jonathan Morton <chromatix99@gmail.com>, "draft-gomez-tcpm-ack-rate-request@ietf.org" <draft-gomez-tcpm-ack-rate-request@ietf.org>, tcpm IETF list <tcpm@ietf.org>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.103.5 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:20:37 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 21 Mar 2022 19:22:40 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/hDw69kBGWvVG4DqMQ6DG-K85kf0>
Subject: Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-request
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: Mon, 21 Mar 2022 18:23:32 -0000

Hi again, Bob,

Please find below my inline responses:

> Carles,
>
> On 12/03/2021 12:27, Carles Gomez Montenegro wrote:
>> Hi Jonathan,
>>
>> Thank you for your quick response!
>>
>> Please find below my inline responses:
>>
>>>> On 12 Mar, 2021, at 12:00 pm, Carles Gomez Montenegro
>>>> <carlesgo@entel.upc.edu> wrote:
>>>>
>>>>> Example:
>>>>>
>>>>>       0                   1                   2                   3
>>>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>      |     Kind      |     Length    |              ExID
>>>>> |
>>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>      |I|X|Value|
>>>>>      +-+-+-+-+-+-+
>>>>>
>>>>> The bit "X"=0 would be equivalent to "R"=0, i.e., immediately request
>>>>> ACKs. In that case, the 6 bit field "Value" could encode the value of
>>>>> "N"
>>>>> described in draft-gomez-tcpm-ack-rate-request-02.
>>>>>
>>>>> The bit "X"=1 would enable delayed ACKs ("R">0) and the 6 bit field
>>>>> "Value" would encode the number that "R" defined in
>>>>> draft-gomez-tcpm-ack-rate-request-02.
>>>>>
>>>>> The "I" bit would be defined as in
>>>>> draft-gomez-tcpm-ack-rate-request-02.
>>>>> (It may make sense to change the order and or naming of the fields,
>>>>> or
>>>>> other details of the encoding - this is just an example.)
>>>> Yes, your proposal above makes sense!
>>>>
>>>>> As far as I can see, there *is* a difference between this encoding
>>>>> and
>>>>> the
>>>>> one in draft-gomez-tcpm-ack-rate-request-02: There is one bit less to
>>>>> encode the value of "R", and two bits less to encode the value of
>>>>> "N".
>>>>> But
>>>>> would that matter? Do we really expect values larger than 63 (or 63)
>>>>> for
>>>>> "R" and "N"?
>>>> Yes, that is a good question, and it would be great to hear what the
>>>> WG
>>>> thinks about that. That is: are there use cases where R or N might
>>>> need
>>>> to
>>>> be greater than 63?
>>> My gut feeling is that values up to 63 are sufficient in both cases.
>> I personally tend to agree... It will be interesting to see if there is
>> any particular use case which might require supporting greater values...
>
> [BB] It all depends how long you want the life of this option to be.
> Let's imagine it becomes common to request a DelACK ratio of cwnd/8.
> Then the option would have to be able to cope with growth in packet
> rates over its lifetime.
>
> Apparently the doubling time of link rate has been about 1.5 years since
> the 1970s (according to Wikipedia's page on Edholm's Law). Let's assume
> growth continues similarly (with no justification other than how else
> can we decide?). I guess it takes about 5 years to get a TCP option
> through the IETF. So to be worth the effort, it's surely got to last at
> least 15-25 years after that, preferably longer. 2^ (30 yr / 1.5 yr) ~=
> 10^6. I.e. TCP might have to handle a window about a million times
> larger than today by the end of life of this option.
>
> If that seems ridiculous, it is. As a sanity check on Edholm's Law, in
> the last 30yrs of TCP (since 1991) that would imply a growth of
> 2^(30/1.5) ~= 10^6 . Given typical TCP windows for Internet access links
> are currently of the order of 100 segments per RTT (30Mb/s with 1500B
> packets over 40ms RTT). Growth of 10^6 to reach only 100 implies TCP's
> window was 0.0001 of a segment in 1991. Clearly daft. What's wrong? Not
> sure. Max packet size has stayed largely unchanged over the public
> Internet., so it's not that. Admittedly doubling time relates to link
> rates, not flow rates. However there's no evidence of more simultaneous
> flows.
>
> Whatever, 63 doesn't seem enough to me.

Thank you so much for such a thoughtful analysis.

We can see that, even if the theoretical growth numbers predicted based on
the Edholm's Law don't seem to match reality, it may be wise to consider a
 maximum value of R covering potential future scenarios (i.e. beyond 63).

>>> It might be possible to contemplate a different encoding which
>>> allocates
>>> more range to one use of the field than the other, but this encoding is
>>> simple enough to be hard to accidentally misinterpret, and that has to
>>> be
>>> considered a Good Thing and weighed against the benefits of any
>>> alternative.
>
> [BB] It certainly seems unnecessary to have as much precision at the
> high end as at the low. No-one will care whether they can set the ack
> ratio to exactly 57 or 56 or 58.
>
> You can divide 6 bits into a 4-bit mantissa (m) and 2-bit exponent (e).
> A couple of schemes come to mind:
> R = (m+1)*2^(2*e)            => min 1; max 1024
> R = (m+1)*2^(4*e)            => min 1; max 65536

Thank you so much for your proposals.

In -03 we are considering your first suggestion above (with max R equal to
1024). It is labelled "OPTION 2".

At this moment, we are keeping also the more simple encoding approach
(with max R equal to 63) in the draft as "OPTION 1" to allow easier
comparison. We plan to ask for feedback about this in the tcpm meeting.

> Note that I don't see the need for R=0 to be special. It means the ack
> ratio is 1. Which is why both formulae above include (m+1).
> I.e. R=0 means ack ratio 1; R=1 means ack ratio 2, and so on (think of R
> as the number of unacked packets between ACKs).

We agree that supporting R=0 is not needed.

Perhaps, once we agree on the encoding for R, we can see whether R or
"R+1" means the ACK rate.

Thanks,

Carles