Subject: A single alarm in draft-ietf-quic-recovery

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Feb 2017 08:40:31 +0100

Hi,

The current version of the draft uses a single alarm for all timer based 
loss detection, as specified in section 3.4 of the draft.

I am not sure i follow how you do this.

I particular, I am uncertain you can avoid having two separated alarms, 
one for the RTO and another one for tail probe (at least).

I mean, if i understand correctly, the RTO alarm should be set when you 
send the oldest packet (I guess a usual approximation is to set it when 
a given packet becomes the oldest, i.e. it is ok to set it when an ack 
arrives and acks the oldest packet (packet 5) making another packet 
(packet 6) to become the oldest packet, instead of setting the alarm 
when packet 6 was actually sent).

I understand that the tail loss probe alarm is set when the last packet 
was sent (and the connection is in open state).

So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and 
suppose no ACK is received.

The RTO timer should be set when packet 1 is sent while the TLP timer 
should be set when the packet 9 is sent.

If i understand it correctly, according to the draft, the alarm will be 
set in TLP mode (twice) and then it wil enter in RTO mode.

Suppose no ack comes back, this basically means that the actual RTO will 
be fired 2 TLP timeout later than the recommended RTO timeout, correct? 
(neglecting the transmission delay for packets 1 to 9 which may not be 
negligible if the number of inflight packets is high)

I think a similar issue applies to the Early retransmit alarm. Again, 
the RTO should be set when the oldest packet is sent, but setting the 
early retransmit alarm will distort this.
I mean again consider the situation the sender sends packets 1,2 and 3.
While no acks are received, the TLP alarm is set. Suppose 1 RTT later, 
the ack for packet 3 arrives. At this point, the Early retransmit timer 
is set. Suppose now that no ack is received. RTT/4 later, the early 
retransmit kicks in again and again and actually the RTO will be never 
be set, because the alarm will always stay in early retransmit mode, no?
Maybe a defining a max number of early retransmit would fix this?
Probably having separated timers would also fix it (assuming we want a 
TCP like behaviour when the oldest packet is retransmitted after an RTO 
timeout)

An additional comment about the Early retransmit timer, the draft 
references to RFC5827 to describe/explain this timer, but I personally 
found this a bit of a stretch. I mean RFC5827, if i understand it 
correctly, is about reducing the dupack threshold when the number of 
inflight packets is low, while this early retransmit timer is, well, a 
timer and it is used in any case when the latest packet has been acked. 
I think this fits better with the "reordering settling" timer (step 4 in 
section 5.2 of the RACK draft) being that the reordering settling timer 
applies to all packets for which a later ack has been received (not only 
the last ack, i mean).
Maybe it is worth to adopt the full "reordering settling" timer from 
RACK (i.e. not limit to the case when the latests packet has been acked?)
I guess if we do this, then we will need the TLP timer and the 
reordering settling timer to run in parallel.

Regards, marcelo