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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 1 May 2020 11:51:19 +0200

Hi Richard,

Thanks a lot for your detailed explanation, pointers and comments.

Please find below my inline responses:

> Hi,
>
>
> as many here know, I'm very much interested in transactional data
> exchange across TCP sessions, rather than the more common architectural
> approach of assuming unlimited data to transmit unidirectional.
>
> One of the issues in that space is, that these application limited
> sessions can very frequently run out of data, and expirience idle periods.
>
> Eliciting an ACK under certain circumstances, for a timely continuation
> of the data transmission / growth of the congestion window is a known
> method to reduce network delay.
>
> E.g. Linux has been using the CWR flag for the purpose of sending out an
> immediate ACK by the receiver, since there is an increased chance of a
> very small cwnd when the sender had just reduced it's congestion window.
>
> https://lore.kernel.org/patchwork/patch/970486/
>
> and we also found latency improvements doing this when running
> ECN-enabled sessions
>
> https://reviews.freebsd.org/D22670
>
> There are also numerous advisories, suggesting to disable delayed ACK
> completely when latency and/or timely bandwidth recovery under
> adversarial conditions is a major driver (e.g.
> https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/esxi7-nfs-read-perf.pdf
> for one that was just published very recently).

This is, all, very useful feedback!

We plan to document the "ACK Pull" approach described above in our draft,
and the associated rationale.

Also, in our draft we currently mention that completely disabling delayed
ACKs might not be a good solution, but as you mentioned, there may be
environments where it may make sense to do so. We will add a note on this
as well.

> To summarize: While I agree that under steady load conditions, there are
> probably some benefits to be had by TCP itself thinning out ACKs, and
> address certain environment (e.g. asymetric link bandwidth), there are
> also conditions, where a timely ACK is crucial in maintaining low
> latency and timely bandwidth recovery. Short of having a mechansim do
> explicitly do this, at least for the latter issue, TLP (or TLP-like)
> methods are the only ones to currently address that - but the duplicate
> unconditional transmission of a (small) data packet does have additional
> cost associated with it.

Thanks for the assessment of the need for ACK thinning and ACK Pull
(depending on the considered scenario).

Cheers,

Carles

> Best regards,
>     Richard
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 1 May 2020 12:22:42 +0200

Hi Neil,

Thanks a lot for your comments!

Please find below my inline responses:

> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard <[email-masked]>
> wrote:
> Yes, agreed.
> IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1
> case.

(While this question is about the solution space, I'm anyway curious...)
In the context of datacenter networks, would you have any suggestion or
preference regarding the solutions that have been mentioned so far?

Or perhaps any particular requirement for a potential solution?

> In datacenter networks the BDPs tend to be so small, and the numbers
> of flows can be so large, that it's not unusual for a flow's fair
> share of the BDP to be one packet or less. If the flows want to
> maintain low queuing delays, then ideally they would be able to reduce
> their cwnd to 1 packet (or effectively even lower, with pacing). But
> the current behavior of TCP delayed ACKs often causes terrible delays
> with a cwnd of 1.

This is very useful input to expand the current section 3.2 of our
requirements draft, which focuses on high bit rate environments.

> The Linux TCP approach of sending an immediate ACK upon receiving a
> packet with CWR set (see Richard's link above) helps a lot with this
> case. But that's a non-standard heuristic, and doesn't help for
> senders that have a congestion control that does not use ECN CWR
> signals (e.g. Accurate ECN). Unless I'm missing something, it seems
> like endpoints using Accurate ECN are going to run into this same
> latency issue. To avoid this, I guess they may want to either use a
> cwnd >= 2, or make use of some new explicit ACK-pull mechanism.

Agreed.

Once again, thanks for your comments!

Carles

> best,
> neal

---

From: Neal Cardwell <[email-masked]>
Date: Fri, 1 May 2020 08:19:38 -0400

> Or perhaps any particular requirement for a potential solution?

Among the solutions outlined in
  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00
my first preference would be the AKP option, since that approach
avoids burning a precious flag bit.

The AKP option may be stripped by some middleboxes, but (a) as a
performance optimization, that should be acceptable, and (b) for the
datacenter case (where cwnd=1 is a motivating use case) this should
not be a concern.

IMHO a flag bit makes sense for a small signal that a sender might
want to send frequently or at a high rate, but senders should not be
trying to force immediate ACKs frequently.

best,
neal

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 1 May 2020 19:20:16 +0100

Neal,

> avoids burning a precious flag bit.

[BB] Eh? AKP does burn a flag bit (and you say it does below). Quoting 
the draft:

    TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of
    the TCP header.

(BTW, Carles, in this quoted sentence, you ought to call it "the TCP ACK 
Pull /proposal/" otherwise sounds like it's an official part of TCP 
already.)

> trying to force immediate ACKs frequently.

[BB] For me, the problem with the AKP approach is that it's /only/ 
really good in environments where you've got a small window. When you 
have a large window and you can cope with a certain ACK ratio (say 
1:16), you would have to set AKP on every 16th packet, which doesn't 
really express what the sender wants (and if the receiver had just sent 
an ACK of its own accord just before it got one of these regular AKP 
requests, should it send another?). The sender in this case really wants 
to say "I don't particularly mind which packets you ACK, but there's no 
need to do it more often than 1:16".

I think there's some mileage in a TCP Option that aggregates a few 
behaviours together under one new TCP Option. I reckon 3 bits would be 
enough for a good delayed ACK option, but a whole TCP Option for that 
could be overkill. There was going to be a talk about a low latency TCP 
Option in netdev0x14 before it was postponed (sorry I don't remember who 
by). That might be a good excuse to collect together a few related 
functions. It could also improve the deployment incentives.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sat, 2 May 2020 10:49:02 +0200

Hi Neal,

> trying to force immediate ACKs frequently.

Thanks a lot for the very useful feedback.

In the next draft update, we will expand the discussion of potential
solutions accordingly.

Cheers,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sat, 2 May 2020 11:39:30 +0200

Hi Bob,

(Chiming in...)

>     TCP ACK Pull defines the AKP flag as bit number 6 of the 13th byte of

[CG] I think that Neal referred to section 5.4 of the requirements draft  
 ("A new 'ACK Pull' TCP option").

> Pull /proposal/" otherwise sounds like it's an official part of TCP

[CG] Well noted, thanks!  (Nevertheless, if that other document went
ahead, I guess that "proposal" would need to be eventually removed.)

> functions. It could also improve the deployment incentives.

[CG] Thanks for the comments!

[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.

Cheers,

Carles

---

From: Neal Cardwell <[email-masked]>
Date: Sat, 2 May 2020 10:10:49 -0400

>  ("A new 'ACK Pull' TCP option").

Yes, as Carles says, when I mentioned "AKP option" I was referring to
the alternative discussed in section 5.4, "A new 'ACK Pull' TCP
option", which does not burn a flag bit:

  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-5.4

When I mentioned "flag bit" I was referring to section 5.3, "TCP ACK
Pull (AKP) flag", which does burn a flag bit:

  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00#section-5.3

> 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://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-00

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".

best,
neal

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 2 May 2020 16:26:21 +0200

> On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=[email-masked]> wrote:
> 
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.

Best regards
Michael

---

From: Neal Cardwell <[email-masked]>
Date: Sat, 2 May 2020 10:34:40 -0400

> > On Sat, May 2, 2020 at 5:40 AM Carles Gomez Montenegro
...
> change the ack rate" by using 0, and encode "change the ack rate to 1 for n"

Yes, that sounds like a very nice idea.

best,
neal

---

From: Matt Mathis <[email-masked]>
Date: Sat, 2 May 2020 07:55:25 -0700

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=
[email-masked]> wrote:

> ....

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 4 May 2020 13:16:01 +0100

On 02/05/2020 15:55, Matt Mathis wrote:
> 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.
>
I agree this might help: The TCP spec lets receivers do this right now, 
if they wish to?
>             too strong would be hypocritical and risks spiraling out 
> of control;

> On Sat, May 2, 2020 at 7:35 AM Neal Cardwell 
> <ncardwell=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > > On 2. May 2020, at 16:10, Neal Cardwell
>     <ncardwell=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >
>     .....
QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio, timing, or 
ACK content, it's likely an extension to the spec in the future. Anyway, 
I don't think TCP is the same as QUIC - TCP's notion of pacing is 
different; TCP's design differs, and there are many flavours and apps 
that use TCP in different ways.

Changing the ACK policy and usage also brings lots of trade-offs: some 
may be good in some use-cases, but also can work out really bad if the 
design doesn't match the application/network path.

>     [email-masked] <mailto:[email-masked]>
I like that also. An option calling for an ACK-now, seems a little 
reminiscent of the way some stacks used "PUSH". I can immediately see 
some good things about eliciting that immediate response for a 
particular sequence number.

Gorry

---

From: Ian Swett <[email-masked]>
Date: Mon, 4 May 2020 09:14:38 -0400

On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst <[email-masked]> wrote:

> I agree this might help: The TCP spec lets receivers do this right now, if
> they wish to?
>
> Thanks,
> --MM--
> ACK content, it's likely an extension to the spec in the future. Anyway, I
> don't think TCP is the same as QUIC - TCP's notion of pacing is different;
> TCP's design differs, and there are many flavours and apps that use TCP in
> different ways.
>

I'm curious about some of these comments.  I agree TCP and QUIC are
different(otherwise why standardize QUIC), but TCP's notion of pacing is no
different from QUIC's in my opinion.  Both have various ways to implement
pacing, and neither has any spec specifying exactly how it should be done.
For TCP, the closest I can find is RFC3449
<https://tools.ietf.org/html/rfc3449#section-4.6>.  You seem to be implying
that the set of apps which use TCP will always be wider than QUIC.  If
anything, I suspect the opposite is true, since QUIC can enable
applications where 100% reliability is undesirable.

> Changing the ACK policy and usage also brings lots of trade-offs: some may
> be good in some use-cases, but also can work out really bad if the design
> doesn't match the application/network path.
>
I completely agree.

> reminiscent of the way some stacks used "PUSH". I can immediately see some
> good things about eliciting that immediate response for a particular
> sequence number.
>
> Gorry
>
> tcpm mailing [email-masked]://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 4 May 2020 14:38:43 +0100

On 04/05/2020 14:14, Ian Swett wrote:
>
>
> On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     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.
>>
>     I agree this might help: The TCP spec lets receivers do this right
>     now, if they wish to?
>>     Thanks,
>>     --MM--
>>                 too strong would be hypocritical and risks spiraling
>>     out of control;
>     QUIC doesn't *YET* have a mechanism to adjust the ACK Ratio,
>     timing, or ACK content, it's likely an extension to the spec in
>     the future. Anyway, I don't think TCP is the same as QUIC - TCP's
>     notion of pacing is different; TCP's design differs, and there are
>     many flavours and apps that use TCP in different ways.
>
>
> different(otherwise why standardize QUIC), but TCP's notion of pacing 
> is no different from QUIC's in my opinion.  Both have various ways to 
> implement pacing, and neither has any spec specifying exactly how it 
> should be done.  For TCP, the closest I can find is RFC3449 
> <https://tools.ietf.org/html/rfc3449#section-4.6>.  You seem to be 
> implying that the set of apps which use TCP will always be wider than 
> QUIC.
QUIC seems to anticipate the need for pacing in its deisgn assumptions - 
I may be wrong? TCP has various recommendations that to me suggest 
pacing is a good idea (I would agree), but I expect lots of stacks do 
not implement burst mitigation.
> If anything, I suspect the opposite is true, since QUIC can enable 

My comment was meant to say there are already a very wide range of 
protocols using TCP. From routing protocols, DNS, to other core 
protocols, to streaming video, to web, bulk transfer, IoT, transaction 
processing, etc. I was hoping to suggest that already many of these 
stacks have been optimised, and we are living with many decades of 
legacy and diversity.

On the other hand, I agree QUIC has applicability to datagrams for 
instance where reliability is not required for data, so I do need to 
learn more about how/whether these will handle CC and pacing, etc.

>     Changing the ACK policy and usage also brings lots of trade-offs:
>     some may be good in some use-cases, but also can work out really
>     bad if the design doesn't match the application/network path.
>
> I completely agree.
>
>     reminiscent of the way some stacks used "PUSH". I can immediately
>     see some good things about eliciting that immediate response for a
-- 
G. Fairhurst, School of Engineering

Gorry

---

From: Ian Swett <[email-masked]>
Date: Mon, 4 May 2020 10:03:55 -0400

Thanks for the clarification.  In implementation, I expect the status of
pacing to be extremely similar for TCP and QUIC.  Many stacks and
applications that do it for TCP will do it for QUIC, and those which don't
pace TCP probably won't bother with QUIC.

On Mon, May 4, 2020 at 9:38 AM Gorry Fairhurst <[email-masked]> wrote:

> implying that the set of apps which use TCP will always be wider than QUIC.
>
> QUIC seems to anticipate the need for pacing in its deisgn assumptions - I
> may be wrong? TCP has various recommendations that to me suggest pacing is
> a good idea (I would agree), but I expect lots of stacks do not implement
> burst mitigation.
>
> protocols using TCP. From routing protocols, DNS, to other core protocols,
> to streaming video, to web, bulk transfer, IoT, transaction processing,
> etc. I was hoping to suggest that already many of these stacks have been
> optimised, and we are living with many decades of legacy and diversity.
>
> instance where reliability is not required for data, so I do need to learn
> more about how/whether these will handle CC and pacing, etc.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 4 May 2020 16:55:28 +0100

On 04/05/2020 15:03, Ian Swett wrote:
> Thanks for the clarification.  In implementation, I expect the status 
> of pacing to be extremely similar for TCP and QUIC.  Many stacks and 
> applications that do it for TCP will do it for QUIC, and those which 
> don't pace TCP probably won't bother with QUIC.

Probably so, time will tell.

Gorry

>
> On Mon, May 4, 2020 at 9:38 AM Gorry Fairhurst <[email-masked] 
>>     On Mon, May 4, 2020 at 8:16 AM Gorry Fairhurst
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         I agree this might help: The TCP spec lets receivers do this
>>         right now, if they wish to?
>>>         Thanks,
>>>         --MM--
>>>                     too strong would be hypocritical and risks
>>>         spiraling out of control;
>>         timing, or ACK content, it's likely an extension to the spec
>>         in the future. Anyway, I don't think TCP is the same as QUIC
>>         - TCP's notion of pacing is different; TCP's design differs,
>>         and there are many flavours and apps that use TCP in
>>         different ways.
>>
>>
>>     I'm curious about some of these comments.  I agree TCP and QUIC
>>     are different(otherwise why standardize QUIC), but TCP's notion
>>     of pacing is no different from QUIC's in my opinion.  Both have
>>     various ways to implement pacing, and neither has any spec
>>     specifying exactly how it should be done. For TCP, the closest I
>>     can find is RFC3449
>     QUIC seems to anticipate the need for pacing in its deisgn
>     assumptions - I may be wrong? TCP has various recommendations that
>     to me suggest pacing is a good idea (I would agree), but I expect
>     lots of stacks do not implement burst mitigation.
>>     If anything, I suspect the opposite is true, since QUIC can
>>     enable applications where 100% reliability is undesirable.
>
>     protocols, to streaming video, to web, bulk transfer, IoT,
>     transaction processing, etc. I was hoping to suggest that already
>     many of these stacks have been optimised, and we are living with
>     many decades of legacy and diversity.
>
>     instance where reliability is not required for data, so I do need
>     to learn more about how/whether these will handle CC and pacing, etc.
>
>>         Changing the ACK policy and usage also brings lots of
>>         trade-offs: some may be good in some use-cases, but also can
>>         work out really bad if the design doesn't match the
>>         application/network path.
>>
>>     I completely agree.
>>
>>         I like that also. An option calling for an ACK-now, seems a
>>         little reminiscent of the way some stacks used "PUSH". I can
>>         immediately see some good things about eliciting that
>>         immediate response for a particular sequence number.
>>
>>         Gorry
>>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 12 May 2020 00:30:30 +0000

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?

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?

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.

Thanks

From: tcpm <[email-masked]> On Behalf Of Matt Mathis
Sent: Saturday, May 2, 2020 7:55 AM
To: Neal Cardwell <ncardwell=[email-masked]>
Cc: Michael Tuexen <[email-masked]>; [email-masked]; Jon Crowcroft <[email-masked]>
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--

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=[email-masked]<mailto:[email-masked]>> wrote:
On Sat, May 2, 2020 at 10:26 AM Michael Tuexen
<[email-masked]<mailto:[email-masked]>> wrote:
>
> > On 2. May 2020, at 16:10, Neal Cardwell <ncardwell=[email-masked]<mailto:[email-masked]>> wrote:
> >
.....
> >  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>
> >

best,
neal

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40microsoft.com%7C38ff3d1d88b245d19a2b08d7eea8ebea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637240282206896363&sdata=lW3W8ONvXw1N02JhAWOpVM4oL6r4JLIFUcqQxzYu%2Fa0%3D&reserved=0>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 13 May 2020 14:00:37 +0200

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
>

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

> <ncardwell=[email-masked]<mailto:[email-masked]>>
> wrote:
>> <ncardwell=[email-masked]<mailto:[email-masked]>>
>> wrote:
>> >

---

From: Joseph Touch <[email-masked]>
Date: Mon, 18 May 2020 08:46:21 -0700

> On May 13, 2020, at 5:00 AM, Carles Gomez Montenegro <[email-masked]> wrote:
> 

Why not start as defining an Experimental Option (with a corresponding code point)?

Joe