Draft: draft-ietf-webtrans-http3

Commentary: FYI , the API PR for a client receiving a DRAINWEBTRANSPORTSESSION capsule is here : A separate issue has been opened for the client sending a DRAINWEBTRANSPORTSESSION capsule : After receiving a DRAINWEBTRANSPORTSESSION capsule from the server , the PR prevents the application from opening new unidirectional or bidirectional streams , but does n't prevent it from continuing to send datagrams . Is that appropriate , or should the application treat receipt of the DRAINWEBTRANSPORTSESSION capsule more like a hint ( e.g. it probably should n't open new unidirectional or bidirectional streams but it 's not prohibited from doing so ) ? 
 Section 4.6 of WebTransport over HTTP/3 ( ) now covers the HTTP/3 GOAWAY frame . When sent from the server -client this indicates that client attempts to construct additional WebTransport objects will fail . Does receipt of a GOAWAY frame need to be indicated to the application , or can it just deal with a ( future ) constructor error ? The DRAINWEBTRANSPORTSESSION capsule PR has been merged , but the draft including the merged PR has not been published yet . 
 An HTTP/3 server needs the ability to gracefully drain existing connections . For HTTP/3 , this involves sending a GOAWAY frame indicating that future requests should use a new HTTP/3 connection . However , the behavior of GOAWAY is partially undefined with WebTransport sessions . After receiving a GOAWAY , the client is no longer able to make new CONNECT requests . This means that any new WebTransport sessions will need to use a new HTTP/3 connection . This is great . However , it 's not clear how existing sessions should behave after receiving a GOAWAY frame . Are they prohibited from creating new streams ? How does this interact with the stream ID sent in the GOAWAY frame ? Should the application expose the receipt of a GOAWAY to start a shutdown process ? 
 Thanks for opening this issue -- it 's been on my mind as well . I think it 's important that we think through all the graceful draining scenarios , including when there are multiple proxies between the WT client and server , and one of the proxies initiates the drain . We already have a use - case which requires a session to be able to create new streams after the receipt of a connection level GOAWAY . We 've been exploring using a GOAWAY with MAXINT to signal the peer to stop creating new sessions , but continuing to all new streams within existing sessions . I do n't think this totally jives with the definition of GOAWAY in the H3 spec , and I do n't think it would work if there were 3 or more intermediaries . What would happen if WebTransport defined a GOAWAY frame that could be sent on the CONNECT stream to signal the intent to drain a session , but not the connection ? 
 I think we should inform application of GOAWAY signal , and possibly add a GOAWAY on the CONNECT stream for intermediation between proxies . 
 Chair notes from IETF 112 meeting : no clear consensus in the room to do this . has volunteered to write a PR proposal with justification of use - case to help motivate this . 
 Let me see if I can do the justification here , then draft the PR . a first class mechanism to " make - before - break " is a key reliability feature in HTTP/2 and HTTP/3 . that carry WebTransport sessions but do not originate originate them need a mechanism to tell the application endpoints that draining is happening , so it ca n't be built exclusively into the application protocols /3 GOAWAY is too broad when multiple sessions pooled and multiple proxy hops are involved 's cheap to add a message that carries this signal on the CONNECT stream , and it 's cheap to ignore it if you want to . As a concrete proposal within the current draft using capsules : I do n't think we need to include any stream information in the  , such as the highest peer initiated uni and bidi stream IDs received by this endpoint . Since the signal is delivered to the application endpoints , they can react and generate their own application level signal , if desired . The signal is only useful if it can be delivered to the application . If we agree this is valuable , should we open an issue for W3C ? Writing this up made me realize that the WT over HTTP/3 draft does n't describe how it interacts with GOAWAY . I opened to track that . 
 Chair : discussed in the room at IETF113 , will write a PR
To drain a WebTransport session, either endpoint can send a
DRAIN_WEBTRANSPORT_SESSION capsule.  An endpoint SHOULD NOT initiate
new WebTransport streams or datagram flows after sending or receiving
a DRAIN_WEBTRANSPORT_SESSION capsule.  Both endpoints can continue
sending data on existing streams and datagram flows, but SHOULD
attempt to gracefully terminate the session as quickly as possible.
To drain a WebTransport session, either endpoint can send a
DRAIN_WEBTRANSPORT_SESSION capsule.  After sending or receiving a
DRAIN_WEBTRANSPORT_SESSION capsule, an endpoint MAY continue using
the session but SHOULD attempt to gracefully terminate the session as
soon as possible.