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

[Ian Swett <[e-mail]>]

To summarize my current thinking: I'd like to add/change something in QUIC
that allows experimentation in this space.  Ideally this would be in the
near future(before v1), so we can understand if it's valuable and provide a
well-reasoned recommendation in the recovery doc.

The fast ACK after PING approach seems simple enough to me, but I'm open to
other suggestions as well.

On Tue, Jul 10, 2018 at 12:56 AM Yoshifumi Nishida <[e-mail]>
wrote:

> On Mon, Jul 9, 2018 at 5:47 PM, Ian Swett
> <ianswett=[e-mail]> wrote:
> > 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.
>
> If it's mainly aimed at the TLP and RTO, I'm not very sure if this is
> really effective.
> For TLP and RTO cases, I guess the speed will depend on how fast
> sender sends a probe packet (while avoiding redundancy) rather than
> how fast receiver sends an ack.
> --
> Yoshi
>