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

[Yoshifumi Nishida <[e-mail]>]

Hi,
Just to be clear..  I am a bit skeptical about the effectiveness of it
for (current) TLP, but I am not against having this kind of feature
for future experiments.
People may come up with an interesting idea based on the results of
some experiments.
--
Yoshi

On Tue, Jul 10, 2018 at 6:54 AM, Ian Swett <[e-mail]> wrote:
> 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