Subject: [quicwg/base-drafts] Dead path timeout (#1638)

From: janaiyengar <[email-masked]>
Date: Tue, 07 Aug 2018 12:33:18 -0700

#1614 makes idle timeout more precise, but still leaves open the question of when a path is considered dead.  We still need a path timeout to close paths over which an endpoint cannot reach a peer.

My suggestion here is to have N RTOs be a value that's used for detecting a dead path, for some reasonable value of N (5? 7?). An endpoint can close the connection when a path is considered dead or can wait for a new path to become available (this is extremely useful when migrating from wifi to cell).

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

---

From: ianswett <[email-masked]>
Date: Tue, 07 Aug 2018 13:23:55 -0700

I think this is a wide enough area of exploration that I'd recommend some pretty vague text calling attention to the issue and recommending:
1) At some point(around 3 to 5 RTOs?), consider sending new traffic on a new connection, instead of the existing possibly dead one.
2) At some point(3 to 6 RTOs?), consider creating a new connection, and if that succeeds, but you're not hearing anything back on the exiting connection, close it and retry if possible, and fail if it's not possible.

I suspect the timing of 1 can be earlier than 2, but I have no data to support that.  I think mentioning that relying on the PING triggering the timeout is a reasonable approach, but may be slow to detect dead paths unless a PING is always kept outstanding when a response is expected, which is likely far too aggressive.

-- 
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/1638#issuecomment-411189800

---

From: ianswett <[email-masked]>
Date: Tue, 07 Aug 2018 15:51:04 -0700

Related to this, is #1049 closed?

-- 
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/1638#issuecomment-411227848

---

From: mirjak <[email-masked]>
Date: Thu, 09 Aug 2018 16:45:56 +0000 (UTC)

Is it the transport that should automatically try to reconnect or the application? In the later case it's just the question about when should the transport give up and tell the application and probably to we want to fail the transport fast than TCP usually does? 

-- 
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/1638#issuecomment-411822769

---

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

In a multipath transport, the responsibility for managing paths is usually left to the transport.  There might be cause to provide applications notice of events, and even give them options to control things, but the primary responsibility lies with the transport.

-- 
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/1638#issuecomment-411946799

---

From: mirjak <[email-masked]>
Date: Fri, 10 Aug 2018 02:18:16 -0700

Are we talking about multipath or re-connection (where you start with a new handshake)? I guess it the latter.

However also for multipath it's a tricky question and while mptcp was charter to provide a solution that can work without app layer changes it turns out that you usually need high layer input (because a full mesh between all available IP address is usually not what you want ;-) ).

-- 
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/1638#issuecomment-412027220

---

From: janaiyengar <[email-masked]>
Date: Fri, 10 Aug 2018 13:41:37 -0700

FWIW, SCTP had clear rules about path and connection timeouts, and it used two different numRTOs for them. I think the draft should talk about when to abandon a path and when to abandon a connection, but not recommend what should be done in terms of retrying new connections.

-- 
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/1638#issuecomment-412200135