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

[Bob Briscoe <[e-mail]>]

Carles,

It strikes me that there is a lot of interest in doing something like 
ACK-pull, but also a lot of disagreement in where to draw the line 
between what to do and what not to do.

Can I suggest that a way to resolve this would be to start with an 
informational requirements draft, that I am sure would be adopted as WG 
business immediately given the interest. Whereas any particular choice 
of mechanism at this stage would probably not get the necessary 
consensus to be adopted.

The requirements draft could discuss solutions, not as a "on this we all 
agree" protocol, but in terms of their pros and cons, e.g. which 
mechanisms could satisfy which requirements, so they can be judged 
relative to each mechanism's complexity / traversibility / usage of bits 
/ etc.

I will warn you that a requirements draft could itself add years to the 
process (the accurate ECN requirements did [RFC7560]). But not if we 
agree to allow a solution draft to start in parallel once the 
requirements are starting to converge, rather than waiting for the 
requirements to go thru the full RFC process.


You might prefer to continue evangelising ack-pull as a sufficient 
solution, so I don't want to say a requirements draft is the only way 
forward. But you saw my comment earlier - that once you've been through 
all the years of effort of getting anything changed in TCP, you 
sometimes feel that you wish you'd been more ambitious than just one bit 
at the start.


Bob

On 10/12/2019 13:37, Scheffenegger, Richard wrote:
>
> 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,
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>

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