Draft: draft-ietf-webtrans-http3

Commentary: The draft says that all streams need to be closed when the WebTransport session is closed . This makes me wonder : error code to use for that ? Should we mandate using the same error code that the WebTransport session was closed with ? tracking : If it 's the WebTransport implementation 's responsibility to reset all the stream , this means that I need to keep another list / map of streams ( outside of my QUIC stack ) . The interesting question is how to garbage collect closed streams from that list . It seems like the only way to do so is by introducing a callback for my QUIC stack to signal that a stream was closed / reset in both directions , so I can clean it up on the WebTransport layer . 
 Regarding the first issue , I was going to add a separate error code , but forgot to . Wrote to address this . Regarding the second issue , I am not sure what the question here . In Chromium , we keep a list of stream IDs for every WebTransport session , and call Reset ( ) on all stream once the CONNECT stream is closed . 
 gentle ping 
 fixes the issue . Regarding my second point , I assume that most implementations will actually keep a second map of streams around , but that 's an implementation detail that we probably do n't need to address in the spec . 
 The draft currently states : It 's clear that without a CONNECT stream that new streams can not be created and datagrams can not be sent , but WT streams that were opened for that session could continue operating normally . This is how push streams are handled in H2 and H3 -- the push stream continues even if the associated stream is terminated . An endpoint always has the option to reset / stop sending WT streams when the session terminates . This is somewhat related to the graceful drain issue ( ) 
 Discussed at IETF 110 . We should keep the current behavior for now , and revisit once we have more implementation experience . 
 Chair : discussed at 113 , consensus in room to have close of CONNECT stream close all webtransport streams and datagrams . will double - check that this is what the draft currently says 
 Draft says : That should be sufficient ( I 've opened to add an error code ) 
 QuicTransport identifies itself using an ALPN and both peers agree to transfer additional configuration via a client - initiated stream ( ID 2 ) . I think it would be an improvement if this origin indication was moved into the QUIC transport parameters and exchanged via the TLS ClientHello . There would be a few benefits ( in no particular order ): server can terminate an invalid origin / path prior to performing the expensive TLS handshake . server does not need to buffer stream data ( inbound and outbound ) waiting until stream 2 has arrived . load balancer can route new connections to the correct server based on the path in the ClientHello . Currently , a load balancer must terminate TLS and buffer all streams until it can parse stream 2 prior to making a routing decision . stream IDs could be exposed to the application without the asterisks that stream 2 has already been used . first client packet ( ClientHello ) must already be padded to 1200 bytes . The origin and path parameters would replace some of that padding and overall reduce the bandwidth for a new connection . There would be a few downsides : paths and origins could cause fragment the ClientHello message into multiple packets . and . libraries need to expose or support the new transport parameters . 
 One more downside : path and origin wo n't be encrypted . This leaks more information than SNI alone and would especially be a problem if ESNI is the future . Yeah , unfortunately I think this alone is a reason to stick with the stream 2 approach . Thanks for letting me think out loud ! 
 Yeah , that 's pretty much the reason why stream 2 exists ( we tried a few ways to limit ourselves to transport params , but those did n't work out ) . It 's possible that we could use for this , but ALPS is still in very early stage , so it 's hard to tell if it will be useful .
WebTransport data stream reset because the associated WebTransport
session has been closed.
WebTransport data stream aborted because the associated
WebTransport session has been closed.