Re: [tcpm] More motivating scenarios for tcpm-ack-pull

["Scheffenegger, Richard" <[e-mail]>]

I believe your list here misses the AckCC option of RFC5690 (which is
only informational, not even experimental). Am Ack Ratio option of 1
followed by a an Ack Ratio of n could serve the same purpose...

Note that there have been multiple investigations showing good
traversability of new options across middleboxes nowadays.

Best regards,
    Richard


Am 07.12.2019 um 12:30 schrieb Carles Gomez Montenegro:
> ess how the patch you mention offers a way
> to trigger immediate ACKs, and the related context and benefits.
>
> Perhaps a combination or (re)use of existing TCP header fields (e.g.
> CWR/PSH as per your suggestion below, or the Urgent pointer as suggested
> earlier by Bob) could be a way to enable triggering immediate ACKs.
>
> A concern with these techniques is that they are limited to some extent.
> For example, some applications produce small segments with the PSH flag
> set and benefit from Delayed ACKs (e.g. to piggyback ACKs and replies). In
> those cases, even regardless of the CWR flag, triggering immediate ACKs
> will avoid achieving performance benefits of Delayed ACKs.
>
> In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we
> propose in the draft) will not suffer such limitations. However, that
> resource needs to be allocated.
>
> Summarizing, there may be two approaches to enable ACK Pull:
>
> 1.- Overloading semantics of existing TCP header fields.
> 2.- Dedicating a resource.
>
> Then the question is, considering pros and cons of both approaches: which
> one do we prefer?
>
> It would be great to hear the WG feedback on the above question!
>
> Thanks,