[quicwg/base-drafts] should we have more than 1 timer per connection for loss recovery (#575)

Subodh Iyengar <notifications@github.com> Mon, 05 June 2017 13:28 UTC

Date: Mon, 05 Jun 2017 06:28:07 -0700
From: Subodh Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab94bef45bb94d3bbe2e65ea9e9c364f649e6014eb92cf00000001154d1e6792a169ce0dec430e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/575@github.com>
Subject: [quicwg/base-drafts] should we have more than 1 timer per connection for loss recovery (#575)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59355c671c3c0_92153ff53fa03c2c589b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/EgbcUhkvnjHQg3Khq79oxXYHmKU>

>From my reading of the loss recovery draft, we have 1 timer per conn and then every time we send a packet, we reset the loss timer.

However let's say we're on a path where ACK packets keep getting lost and the sender is trickling packets on the connection just before the timer fires, it seems like we will never hit RTO at all since

OnPacketSent() always invokes SetLossDetectionAlarm() which will always keep advancing the deadline of the RTO timer.

Should we have multiple timers per packet to avoid this?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/575

[quicwg/base-drafts] should we have more than 1 t… Subodh Iyengar
Re: [quicwg/base-drafts] Number of loss detection… ianswett
Re: [quicwg/base-drafts] Number of loss detection… Subodh Iyengar
Re: [quicwg/base-drafts] Number of loss detection… ianswett
Re: [quicwg/base-drafts] Number of loss detection… ianswett