Re: [tcpm] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP

[Carles Gomez Montenegro <[e-mail]>]

Hi Praveen,

Thanks for your comments.

Please find below some inline responses and comments:

> I agree with the two use-case taxonomy. While it'd be quite nice to have a
> single mechanism like a TCP option that addresses both use cases, there
> are problems with a new option that's used in data packets:
>
> 1. middlebox traversal
>
> 2. hardware offloads like TSO and LRO might need updates?

Indeed, our analysis in draft-gomez-tcpm-delack-suppr-reqs-01 shows that
all potential solutions considered so far, including new TCP options,
appear to have pros and cons.

In order to evaluate solutions, I think the most critical part is
determining what could be an acceptable trade-off among different goals or
requirements.

In this thread, several WG participants expressed a positive opinion about
defining a new TCP option. (Although, as you mentioned, this approach also
has drawbacks.)

> If we go down the path of a new option for data packets that is broadly
> deployed, should we aim for a list of key-value pairs so that it is
> extensible?

Capturing what Neal and Michael outlined, we might consider a new TCP
option with the following format and intended functionality:


       Kind: TBD

       Length: 3 bytes

       Format:

              +---------+---------+---------+
              |Kind=TBD |Length=3 |    N    |
              +---------+---------+---------+
                   1         1         1

       N=0 --> "Please, ACK now (but don't change the ACK rate)"
       N>0 --> "Change the ACK rate to 1 every N received data segments"

Would the above (where the "N" field has a size of 1 byte) suffice, or
would you still envision the need for a list of key-value pairs (or did
you have a different approach in mind)?

> Also, I recall there was some discussion about usage of PSH bit for ACK
> pull. It’s already used for signaling message boundary, so an immediate
> ACK upon end of message might also help lower latency.

A problem that has been reported is that, when the PSH bit is set, it is
not always desirable to trigger an ACK immediately:
https://mailarchive.ietf.org/arch/msg/tcpm/seVEB4XAPjixXOPqfPea7zZAVmU/

Thanks,

Carles



> Thanks
>
> From: tcpm <[e-mail]> On Behalf Of Matt Mathis
> Sent: Saturday, May 2, 2020 7:55 AM
> To: Neal Cardwell <ncardwell=[e-mail]>
> Cc: Michael Tuexen <[e-mail]>; [e-mail]; Jon
> Crowcroft <[e-mail]>
> Subject: [EXTERNAL] Re: [tcpm] On Sender Control of Delayed Acks in TCP
>
> Another probably small opportunity would be to make the RTT estimators
> less noisy, by having the receiver always ACK the first (or last) TSO
> segment.   The RTT is currently fuzzed by both del ACK and TCP strides.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> We must not tolerate intolerance;
>        however our response must be carefully measured:
>             too strong would be hypocritical and risks spiraling out of
> control;
>             too weak risks being mistaken for tacit approval.
>
>
> On Sat, May 2, 2020 at 7:35 AM Neal Cardwell
> <ncardwell=[e-mail]<mailto:[e-mail]>>
> wrote:
> On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
> <[e-mail]<mailto:[e-mail]>>
> wrote:
>>
>> > On 2. May 2020, at 16:10, Neal Cardwell
>> <ncardwell=[e-mail]<mailto:[e-mail]>>
>> wrote:
>> >
>> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
> .....
>> >> [CG] It seems that there are two different areas where avoiding the
>> >> typical Delayed ACKs approach may be of particular interest: i)
>> scenarios
>> >> where very small window sizes are used (cwnd=1), and ii) scenarios
>> where
>> >> large window sizes, and high ACK ratios, can be used. We will
>> reflect
>> >> these considerations in the next draft update.
>> >
>> > Yes, I wholeheartedly agree with Bob's point that it's also extremely
>> > useful for TCP senders to be able to say things like: "I don't
>> > particularly mind which packets you ACK, but there's no need to do it
>> > more often than 1:16". QUIC has a mechanism like this, and it seems
>> to
>> > allow significant CPU savings, even allowing QUIC to run faster than
>> > TCP in some cases, AFAICT due to the reduced overhead for handling
>> > ACKs:
>> >  https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fastly.com%2Fblog%2Fmeasuring-quic-vs-tcp-computational-efficiency&data=02%7C01%7Cpravb%40microsoft.com%7C38ff3d1d88b245d19a2b08d7eea8ebea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637240282206886368&sdata=Uv%2B%2FgUOkvXss66hcGohqnt3tRHK4g3imDt0I0mu5xRw%3D&reserved=0>
>> >  https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-iyengar-quic-delayed-ack-00&data=02%7C01%7Cpravb%40microsoft.com%7C38ff3d1d88b245d19a2b08d7eea8ebea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637240282206886368&sdata=9vw3sjqTAPLPCNAQPCFza3RJSLY%2B25T8Odqq0PCec%2BE%3D&reserved=0>
>> >
>> > So I agree with the usefulness of the two-use-case taxonomy Carles has
>> outlined:
>> >
>> > 1: "please ACK now"; because sender's cwnd is low
>> >
>> > 2: "ACK at frequency K"; because sender's cwnd is high
>> >
>> > It seems those could both be addressed cleanly with one or two TCP
>> > option kinds. A single TCP option kind might suffice if the ACK
>> > frequency of 0 or 1 is taken to mean "please ACK now".
>> I might be useful if the sender can trigger an ACK for this particular
>> packet,
>> but leave the rate unchanged. And change the rate from now on.
>> If using an option, you could encode "send an ack for this packet, but
>> don't
>> change the ack rate" by using 0, and encode "change the ack rate to 1
>> for n"
>> by using n, n > 0.
>
> Yes, that sounds like a very nice idea.
>
> best,
> neal