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

[Praveen Balasubramanian <[e-mail]>]

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.

Ideally this should say:
	The receiver of a PING frame SHOULD send an immediate ACK acknowledging the packet containing this frame.

> that there are cases that a sender wants to trigger immediate ACK even if gap is not observed on the receiver side
If this is for timing measurements or liveness then PING should work. If you have examples where loss recovery can be further improved using such a mechanism then we should certainly address it. I don’t think we can make any assumptions on the sender that receiver will ACK because pure ACK can also be dropped and not retransmitted.

-----Original Message-----
From: Kazuho Oku [mailto:[e-mail]] 
Sent: Sunday, July 1, 2018 9:28 AM
To: Lubashev, Igor <[e-mail]>; Praveen Balasubramanian <[e-mail]>
Cc: huitema <[e-mail]>; [e-mail]
Subject: Re: Speeding up tail loss detection (Re: Congestion control algorithm questions)

2018-06-30 12:43 GMT+09:00 Lubashev, Igor <[e-mail]>:
> It would make sense to define PING to require an ACK as soon as possible.
> The need for an immediate ACK is not just in tail loss probes. It is 
> also PMTU probes. Come to think of this, PATH_CHALLENGE should require 
> an expedited ACK as well.

That approach would work well.

In my view, there are two ways; i) define a frame that requests immediate ACK, and bundle that frame with other frames if immediate ACK is required, ii) define which frames trigger immediate ACK. I think either of the two are workable.

Re Praveen's comment, my understanding is that there are cases that a sender wants to trigger immediate ACK even if gap is not observed on the receiver side. In case of TLP, such behavior is desirable because it gives the peers to recover earlier from the loss of a previous packet that contained an ACK.

>
> - Igor
>
>
> -----Original Message-----
> From: Kazuho Oku [[e-mail]]
> Received: Friday, 29 Jun 2018, 11:14PM
> To: Christian Huitema [[e-mail]]
> CC: IETF QUIC WG [[e-mail]]
> Subject: Speeding up tail loss detection (Re: Congestion control 
> algorithm
> questions)
>
> I know that the recovery draft defines TLP, but it does not provide a 
> way for a sender to request client to send an ACK immediately. I think 
> that there should be a way to request that, because it would help the 
> sender detect the loss at the earliest moment.
>
> One way is to specify a TLP frame, which is identical to a PING frame 
> with only one difference: it suggests the peer to send ACK 
> immediately. A sender sending a TLP will include the frame in the 
> packet to evoke the peer to send ACK without waiting for the delay.
>
> Searching the mailing list archive told me that Christian raised the 
> issue about a year ago (in the mail cited below), but it seems to me 
> that the issue has not been resolved yet.
>
> 2017-08-25 14:52 GMT+09:00 Christian Huitema <[e-mail]>:
>
>> 3) Can the senders do something to speed up retransmission?
>> In the absence of continuous traffic flow, the previous decision tree 
>> degenerates to timer based retransmission. To speed things up, 
>> implementations can generate extra traffic. For example, if no 
>> acknowledgement is received after a short timer, they can send a 
>> gratuitous packet that may trigger a further acknowledgement. That's 
>> the essence of the "tail loss probe" algorithm of TCP, but things are 
>> really simpler with monotonously increasing packet sequence numbers. 
>> There are various plausible ways to send a gratuitous packet -- a 
>> Ping, a Max Data Update, or repeating the oldest packet will all work.
>>
>> Of course, implementations should avoid sending too many gratuitous 
>> packets, because it can cause congestion. The typical implementation 
>> will wait one min-RTT before sending the first tail loss probe, then 
>> just wait for the regular timer based retransmission. But we may 
>> start being creative. For example, if packets are waiting and the 
>> implementation is sending a naked ACK for whatever reason, it does 
>> not cost much to add a Ping to that.
>>
>> This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it 
>> is very easy to implement.
>>
>> --
>> Christian Huitema
>>
>>
>
>
>
> --
> Kazuho Oku
>



--
Kazuho Oku