Re: [openscreenprotocol] [QUIC] Define suspend and resume behavior for connection protocol (#108)

The following issues are some that come to mind on this topic:
 - W.r.t. the QUIC spec, the PING frame in QUIC is specifically for keeping both the QUIC connection (because of `idle_timeout`) and the intermediate path state (e.g. middle box/NAT state) alive.  Suspend/resume would either need to still allow sending PINGs (and therefore buffering receives) or do nothing and just test the connections after resume.
 - Similarly, if no received data will be processed during suspend, the other endpoint might think many packets are being dropped or delayed.  Even if the connection is still active on resumption, the congestion control algorithm of the other endpoint will have been negatively affected by the sleep period.  It might be beneficial/necessary to communicate with a CBOR message that we are suspending/resuming, though incorporating that into the QUIC flow control implementation would probably be very difficult.
 - At the OSP implementation level, we would need to decide whether other parts of the implementation (e.g. Presentation API Controller implementation) can still write to QUIC streams and the data is buffered, or whether writes should be rejected during suspension.

-- 
GitHub Notification of comment by btolsch
Please view or discuss this issue at https://github.com/webscreens/openscreenprotocol/issues/108#issuecomment-444305096 using your GitHub account

Received on Tuesday, 4 December 2018 23:55:43 UTC