search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
87 stars 22 forks source link

No mention of H3 GOAWAY or WT drain #535

Open LPardue opened 2 months ago

LPardue commented 2 months ago

MoQT defines its own GOAWAY drain, thats fine. But it probably needs to refer to H3 and WT in a similar way that WT does in https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-10#section-4.6. In other words, MoQT is building a 3rd mechanism and any folks that might use the other two could be in for a surprise. So I think there needs to be some text about the expected interactions.

afrind commented 1 month ago

Hopefully we don't need to mention H3 GOAWAY specifically, and WT will handle that bit for us (and any other protocols on WT), and it ought to mean "You can't make any new WebTransport sessions above the parameter in GOAWAY".

We do need to address DRAIN_WEBTRANSPORT_SESSION, but unfortunately I don't think we can completely remove moq GOAWAY, since raw QUIC has no equivalent.

LPardue commented 1 month ago

Yeah I think MoQT does need it's own GOAWAY and just a small amount of text is needed.

However, I'm not sure you can completely omit mention of H3 GOAWAY. WT makes it pretty clear that if you receive one, it's an indicator to start closing all webtransport sessions. There's a bit if a race here, if a client receives H3 GOAWAY, it won't know the URI to migrate to and it might have to wait indefinitely. We should consider some text for a) whether a client should wait on receiving MoQT GOAWAY (and for how long) before deciding to tidy up WT state b) whether it can safely assume that it can retry with the same URI or not.

ianswett commented 1 month ago

I wish QUIC had it's own GOAWAY. I generally think of the WebTransport and QUIC API surfaces being identical and this is a spot they clearly differ. And ALPN, but in theory that's fixed?