Subject: [quicwg/base-drafts] Add another condition to idle timeout (#1648)

From: Subodh Iyengar <[email-masked]>
Date: Thu, 09 Aug 2018 19:56:55 -0700

When implementing the new idle timeout, I noticed that there might be one condition missing from this. 

Previously if you send the first packet in the connection or send the first packet after all your ACKs are received / packets lost, then your idle timeout will not be set.

This changes it so that when there are no outstanding packets and you send a packet, it resets the idle timeout.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1648

-- Commit Summary --

  * Add another condition to idle timeout

-- File Changes --

    M draft-ietf-quic-transport.md (11)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1648.patch
https://github.com/quicwg/base-drafts/pull/1648.diff

-- 
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/pull/1648

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Aug 2018 21:53:15 -0700

Is this new condition better than the one @ianswett suggested?  That is, should it replace that condition instead of adding a new one?

If you think about it, the last packet you send before an idle period is almost always sent with no other packets outstanding.  If you receive an ACK, then you send nothing.  Otherwise, you send an ACK after a short delay, which would generally fit with this new definition.

-- 
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/pull/1648#issuecomment-411974831

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 10 Aug 2018 19:55:12 +0000 (UTC)

You have a good point. The only difference I see in these 2 conditions is that the previous one covers the case that you have a few packets outstanding and then you receive a packet. However it's probably not that useful since presumably if you have a few packets outstanding, you expect to get feedback about them still. So I think that we can actually replace the condition with this new one of outstandingpackets.size = 0. It's also much simpler to implement as well.

-- 
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/pull/1648#issuecomment-412188642

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Aug 2018 17:54:26 -0700

What about outstanding ACK-only packets?  Those won't be declared lost.  Let's say that the last thing that happened was that an endpoint receives a packet containing something useful (e.g., STREAM).  It sends a packet with an ACK, then goes idle.  That ACK-only packet is technically still outstanding.  See #1652.

-- 
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/pull/1648#issuecomment-412384143

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Aug 2018 17:57:28 -0700

Closed #1648 via #1652.

-- 
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/pull/1648#event-1789124206