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

From: "Aron ." <[email-masked]>
Date: Thu, 2 Mar 2017 15:22:21 -0500

I think Marcelo poses interesting questions.  I, too, would like to see the
answers.

  Aron.

On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun <[email-masked]>
wrote:

> 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
>
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 3 Mar 2017 12:03:04 -0500

Great questions, sorry for the delay.  Answers inline.

> was sent (and the connection is in open state).

QUIC sets the RTO alarm based on the most recently sent packet, just like
TLP, and it always sends TLPs before arming the RTO timer.  These are two
subtle but significant difference from how TLP and RTO are defined in TCP.
Both are less aggressive than TCP, which I tend to think is good in this
case.  QUIC's goal is to continue making forward progress, not only move
the left edge forward, so we didn't see a need to have two competing
retransmission timers for almost identical purposes.

Another important difference is that QUIC's TLP retransmits the earliest
outstanding packet when no new data is available, not the most recent,
under the theory it's more likely to be lost and QUIC's packet numbers
means there are no issues with ambiguity.

> negligible if the number of inflight packets is high)

That's correct and intended.

> like behaviour when the oldest packet is retransmitted after an RTO timeout)
The intent was that when the early retransmit timer went off after 1/4 RTT,
all packets less than the largest acked would be declared lost, which I
believe is the TCP behavior for early retransmit as well(with the addition
of a timer).  But as you note, that's not properly stated in the document,
so I'll fix that in a PR.

> settling timer to run in parallel.

You're correct, early retransmit comes from RFC5827, but the timer is
mentioned as an improvement described in a paper I'm unable to locate at
the moment and also implemented in Linux.

I believe "reordering settling" is similar to use_time_loss mode.  The
pseudocode is intended to be written in a way to describe both nack based
loss detection and time based detection(which uses the timer, similar to
RACK), but now that I re-read through it, it's insufficiently specified for
time loss mode, so I'm working on a PR to fix that.  RACK didn't exist when
QUIC's nack and time loss detection were written, so it's possible there's
some opportunity for syncing up their descriptions.

> Regards, marcelo

I'll add some text clarifying some of the difference from TCP and adding
some justification after fixing the time loss and early retransmit issues.
QUIC's approach is much more closely modeled on recent Linux TCP
implementations than IETF RFCs, but many details are subtly or
not-so-subtly different because data is rebundled into new packets, instead
of retransmitting packets.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 5 Mar 2017 05:46:51 -0800

On Fri, Mar 3, 2017 at 9:03 AM, Ian Swett <[email-masked]> wrote:

> On Tue, Feb 21, 2017 at 2:40 AM, marcelo bagnulo braun <[email-masked]
> > wrote:
>
>> Hi,
>>

let's say if we send 2 packets almost simultaneously, the alarm duration
will be set to (2 * srtt)?
(I presume srtt is larger than kMinTLPTimeout here)

and, if we send 3 packets almost simultaneously, the alarm duration will be
set to (srtt + 4 * rttvar)?
If this is correct, depends on rttvar, we might wait longer when we send 2
packets?

BTW, The draft says:

   o  tlp_count: The number of times a tail loss probe has been sent
      without receiving an ack.

   o  rto_count: The number of times an rto has been sent without
      receiving an ack.

Are these correct? It seems to me that they are the number of times alarms
have been set.

BTW, I think it would be great if you could put a call graph for these
pseudo functions in the feature version if possible.

Thanks,
--
Yoshi