Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

[Ian Swett <[e-mail]>]

This has been discussed on and off for a few years now, even prior to the
IETF process.  It's never been clear that adding a frame for this purpose,
or altering the behavior of an existing frame(ie: PING or STREAM) is
valuable.

I'm about to start an experiment to send an ACK more quickly(ie: 1ms delay)
if it's been over an RTT since an ACK has been sent, which may help, but is
largely aimed at the TLP and RTO use cases.  One use case that's been
discussed is sending a fast ack frame/signal when entering an app-limited
phase.  This seems fairly promising to me, but I have no experimental
evidence it actually helps.

One option would be to recommend sending an ACK quickly in response to a
PING, unless a PING has been acked within the last RTT.  This would provide
a natural rate-limit to immediate ACKs.


On Sun, Jul 1, 2018 at 1:20 PM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> On 1 July 2018 at 18..32.56, Praveen Balasubramanian (
> pravb=[e-mail]) wrote:
>
> Doesn’t the PING frame serves this purpose? The language in the transport
> draft isn’t very clear:
> The receiver of a PING frame simply needs to acknowledge the packet
> containing this frame.
>
>
>
> No, I asked for this several times, but there was no traction. It is
> ACK’ed as any packet which the consensus considers soon enough. But I dont’
> think this takes into account use cases with delayed ACK and congestion
> algorithms that can tolerate longer delays.
>
> It’s simply useful to ping in order to get a roundtrip time on the
> connection, aside from what has already been mentioned.
>