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

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

Hi Jonathan,

First of all, sorry for the late reply.

Thanks a lot for your comments. Please find below our inline responses:

>> On 15 Mar, 2020, at 11:38 am, Carles Gomez Montenegro
>> <[e-mail]> wrote:
>>
>> Thanks a lot for your detailed response, which helped shape our latest
>> draft [1] in several ways.
>>
>> While we focus on analyzing the problem space and its requirements, it
>> will be good to keep an eye on potential solutions as well, including
>> the
>> one you describe below. In particular, I found the idea of spacing AKP
>> flags (or something similar) in order to control the desired ACK ratio
>> to
>> be very interesting!
>
> I'm glad you found my comment useful.
>
> I think one of the big takeaways from draft-gomez-tcpm-delack-suppr-reqs
> is that the sender has the most information about when, and to what
> extent, Delayed Acks are helpful, but the receiver is the point at which
> they must be implemented. So some means to convey this information from
> sender to receiver is desirable.  The precise form of that is still open
> to debate.

Thanks for your conclusions and assessment.

We agree that the form to convey this information from sender to receiver
is open to debate. We hope that section 5 of our document can contribute
to the discussion!

> And there are well-known circumstances where the receiver already has to
> interrupt or suspend Delayed Ack processing - when it notices a packet
> loss, or receives an ECN mark, for example.  I assume these would not
> change materially on a transport supporting Ack Pull or similar.

In fact, there is a new subsection (4.10), suggested by Bob, that mentions
that the receiver might sometimes be unable to honour the ACK ratio or ACK
behavior desired by the sender (this relates also to your first paragraph
above). In a subsequent revision, we'll be more specific about
circumstances such as the ones you mention above.

Once again, thanks a lot for your comments!

Cheers,

Carles


>  - Jonathan Morton
>
>