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
- [tcpm] Question on draft-gomez-tcpm-ack-rate-requ… Scharf, Michael
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Carles Gomez Montenegro
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Jonathan Morton
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Carles Gomez Montenegro
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Bob Briscoe
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Carles Gomez Montenegro
- Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-… Carles Gomez Montenegro