Subject: [quicwg/base-drafts] When are missing Q-thingey references fatal? (#1176)

From: Mike Bishop <[email-masked]>
Date: Thu, 08 Mar 2018 16:16:55 -0800

@afrind raises a good hypothetical case:

- Encoder sends a header block on a request stream, which is delayed in the network
- Encoder side resets the stream, which is lost in the network
- Encoder sends another header block on the control stream that evicts an entry referenced in the first block, and this is delivered immediately.
- The first delayed header block arrives

>From the encoder's side, it's valid to evict something referenced by the first block, because the stream has been reset.  From the decoder's side, there's a reference to something already evicted, because it doesn't know about the stream reset.

The solution to this seems to be that missing references on request/push streams are stream errors, not connection errors.  Missing references on the control stream still need to be connection errors.

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

---

From: afrind <[email-masked]>
Date: Fri, 09 Mar 2018 17:15:08 +0000 (UTC)

I think the scenario that leads to this kind of error will be extremely rare, but I dislike the idea of there being some background level of 'expected' decoding errors.  It will make it harder to debug/investigate buggy implementations.  In the case where the missing reference came from an encoder that is broken or otherwise out of sync with the decoder, worse things could happen from continuing to decode subsequent requests.

The only other way I can think of to ensure such a scenario doesn't inadvertently kill a good connection is to have the encoder clear the outstanding references of the reset stream only after it's received the ACK for that RST_STEAM.  I'm already not crazy about having transport identifiers tied into header encoding state, and having to further couple to transport acknowledgements would be even worse.  Still, a careful encoder could take this approach.

-- 
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/1176#issuecomment-371879005

---

From: krasic <[email-masked]>
Date: Fri, 09 Mar 2018 17:46:15 +0000 (UTC)

+1 that moving to stream errors might introduce greater harm than they solve.   

This is similar to the more general reset issue we hoped to avoid moving updates out of the request-response stream.  

As in that discussion, another option is to have the encoder refrain from resetting streams that have outstanding headers.   I.e. an HQ mapping only solution is possible here:

the encoder side can have a notion of stream going away (don't send new data, drop any incoming data, don't start any new headers), but wait for header acks before actually sending reset.   To stay conservative, it could use a timer to trigger sending the reset anyway if the expected ack takes too long.  [ of course if we went this far, one might argue the whole update on separate stream approach is no longer needed. ]

Alternatively, if the occurrences of these are rare enough, perhaps status quo of letting such connections close with error is acceptable.   A server could track how many streams are reset with headers outstanding to help guage whether the number of missing header connection close errors are reasonable.

-- 
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/1176#issuecomment-371888920