Subject: Re: sending an retransmitting packets in draft-ietf-quic-recovery

From: Martin Duke <[email-masked]>
Date: Thu, 2 Mar 2017 16:32:04 -0800

Some additional issues with this draft:

- What is (acked_packet) when the alarm fires?

- I'm not sure how DetectLostPackets supports RTOs. If we only iterate
until reaching the largest acked packet, then we'll never check packets
beyond that for loss.

On Mon, Feb 20, 2017 at 1:18 AM, marcelo bagnulo braun <[email-masked]>
wrote:

> Hi,
>
> I am going though the loss detection algorithm described in section 3 of
> draft-ietf-quic-recovery-01 and I have a question.
>
> I see that the MaybeRetransmitLostPackets() function is only called on
> Alarm firing. In particular, the
> MaybeRetransmitLostPackets() is not called when receiving in ack.
>
> Is that a mistake?
>
> I find strange that upon reception of an ACK, that determines that some
> packets are lost, the retransmission function is called right away but a
> timer is set and retransmission is triggered RTT/4 time later.
>
> Also, I guess upon ack reception, if no loss is detected but the windows
> moves, new data should be transmitted and while i understand that the loss
> detection algorithm may not be the right place to define the rules for
> transmitting new packets, it may be worth mentioning it.
>
> Regards, marcelo
>
>

---

From: Ian Swett <[email-masked]>
Date: Mon, 6 Mar 2017 15:33:50 -0500

Yes, that's a mistake, if receiving an ack causes packets to be considered
lost, then you would try to retransmit them immediately.  I just fixed that
in Github.

I'm not sure how much to go into what one should transmit in the recovery
doc, but I will at least try to add some detail about when it's recommended
to retransmit vs send new data, in line with the recommendations in the
core transport doc.

Martin:
acked_packet is intended to be the largest acked packet, but currently
that's ambiguous.

RTO packets aren't actually considered lost until a larger packet is
acknowledged in QUIC.  If done correctly, this is equivalent to TCP with
F-RTO, but instead of undoing the CWND reduction, you just wait until
knowing if it was a real RTO before enacting the CWND reduction.  That is a
case where the recovery interacts fairly directly with the congestion
controller, and as such, needs to be properly documented.

On Thu, Mar 2, 2017 at 7:32 PM, Martin Duke <[email-masked]> wrote:

> On Mon, Feb 20, 2017 at 1:18 AM, marcelo bagnulo braun <[email-masked]
> > wrote:
>
>> Hi,
>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 6 Mar 2017 13:11:15 -0800

Hi Ian,

> controller, and as such, needs to be properly documented.

Hmm.. Let's say we've sent packet 1 and acked.  Then, I think the largest
acked packet will be 1.
Now, we sent packet 2,3,4,5, but all are lost, so no ACK has been received.
Since DetectLostPackets() always checks unacked packets which are less than
acked_packet, as far as I think these packets won't be checked in the
function.
--
Yoshi