Subject: [quicwg/base-drafts] Propose SLOT Frame (#489)

From: MikkelFJ <[email-masked]>
Date: Mon, 01 May 2017 06:58:12 -0700

A SLOT frame is packet oriented frame which is a simpler version of partially reliable transmission
(https://github.com/quicwg/base-drafts/issues/433).

It could be used in place of Stream 0 for handshake, and for game state services etc.

Semantics: a frame that has data similar to a stream frame, but no offset and it is limited to a single packet always. The frame has a SLOT ID similar to a FRAME ID but the SLOT ID can be reused indefinitely and the frame is not retransmitted. Ordering among slot frames is given by the packet number and the offset withint the packet, but it is not possible to tell how many slot frames were transmitted.

It is possible to have a second SLOT type that has retransmission. Optionally there could also be a sequence counter for the retransmittable slot.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 01 May 2017 17:18:54 -0700

My opinion only.

If the intent of this is to deal with the minor infidelity that sending a HelloRetryRequest introduces, then it is overkill.  If the intent is to define partial reliability, then I think that that this is out of scope (and likely also unnecessary).

-- 
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/489#issuecomment-298466322

---

From: janaiyengar <[email-masked]>
Date: Mon, 01 May 2017 18:38:39 -0700

mikkelfj, partial reliability is currently explicitly out-of-scope. The charter says: "Extensions that will support partial reliability, and negotiation and use of Forward Error Correction schemes, are out of scope in this version of the working group charter."

Marking this as parked.

-- 
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/489#issuecomment-298476473

---

From: MikkelFJ <[email-masked]>
Date: Mon, 01 May 2017 23:36:32 -0700

Fair points - just please consider it as an option if it gets too complicated to formulate a handshake in the current form - there are probably many exceptions to made if stateless streams are to be supported.

-- 
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/489#issuecomment-298509040

---

From: Jānis <[email-masked]>
Date: Tue, 02 May 2017 00:00:57 -0700

I would love to see QUIC supporting non-reliable streams. It could be useful for games, IoT sensors and even VPNs based on QUIC, which all would have smaller performance hit, because of 1-connection (1 asymetric hanshake) with included benefit with easier load balancing (because of the Connection ID).

-- 
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/489#issuecomment-298513856

---

From: janaiyengar <[email-masked]>
Date: Wed, 03 May 2017 15:21:27 -0700

There is definite interest in discussing partial reliability eventually, but it's scoped out of charter for now to allow focus on HTTP.

-- 
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/489#issuecomment-299052204