search

quicwg / qlog

The IETF I-D documents for the qlog format
Other
86 stars 13 forks source link

Make intent of triggers for connection_closed clearer #419

Closed rmarx closed 4 months ago

rmarx commented 5 months ago

Closes #410

@LPardue PTAL. I still think having an application value here is useful (e.g., user force-closed the connection somehow, or application decided to abandon it without waiting for clean shutoff without additional info). But as discussed on #410 the GOAWAY example was probably incorrect.

rmarx commented 5 months ago

Discussed during editors' meeting. Discussion on how useful clean is. Discussion on when connection_close should be emitted (before draining or after draining, if there's a draining involved). Marten feels it should be when draining starts, Lucas has no opinion.

Robin will go back and see what would be most useful and what makes sense with errors logging etc. (i.e., should be emit ConnectionClosed twice or use ConnectionStateUpdated for some things).

Also enforce here that triggers are suggestions, and that other triggers are possible based on application.

Related to #239

rmarx commented 4 months ago

Ok, after spending WAY too much time re-reading the connection close stuff in RFC9000 and 9114, I think I now have something that's still a bit vague, but at least correct :)

The main problem apparently (and why "clean" was needed), is because you have situations where you as a peer receive a CONNECTION_CLOSE where you're not 100% sure what triggered it... (e.g., a transport CONNECTION_CLOSE (0x1c) with transport error code NO_ERROR) is probably clean, but you're not quite sure (could be it was an application-level error on the other end that they simply didn't pipe through correctly).

So I've now renamed that to "unspecified" and added text to say you should try to be as specific as possible... hope that is enough :)

PTAL @LPardue