Thanks again, Robin, for doing this work. I strongly vote for option A -- keep it in QUIC.
I think the most value for this would be in QUIC, primarily because that's where people are actively adopting and using it. I would be reluctant to make this broader yet, if only because our problem at the IETF usually isn't that we have too few people with opinions on data formats (and the color of each field). Practically, we already have multiple QUIC/H3 implementations emitting qlog - and some of them already have feedback on how to extend it to be more useful - so I would suggest that getting meaningful implementation experience is going to be easiest with QUIC/H3 right now. Once it's done for QUIC/H3, I would then do the generalization after as a next step, with other use cases if and where there's interest. RFC numbers are cheap, and you have versioning in this thing. The split you have is fine, and it allows you to generalize this later. But keeping this discussion local to the QUIC WG will be super useful as a first step. - jana On Wed, Nov 25, 2020 at 4:00 PM Martin Duke <martin.h.d...@gmail.com> wrote: > Splitting HTTP/3 and QUIC into separate documents, so they can evolve > separately makes, sense, though I would be comfortable with them both > remaining in QUICWG for now. > > As an AD, I will facilitate a discussion with other areas about the main > schema. Robin, it might be useful for you to go on a roadshow at IETF 110 > to pitch it to other areas to see if there's wider IETF energy to pursue > qlog extensions. If so, the case for putting the main schema outside quicwg > is pretty strong. > > On Mon, Nov 23, 2020 at 12:14 PM Lucas Pardue <lucaspardue.2...@gmail.com> > wrote: > >> Thanks Robin! >> >> I have some responses in line. >> >> On Mon, Nov 23, 2020 at 7:05 PM Robin MARX <robin.m...@uhasselt.be> >> wrote: >> >>> Hello everyone, >>> >>> I was happy to see a large amount of support from you all for qlog at >>> the QUIC wg meeting last week [0]! >>> While it seemed there was consensus that it would benefit from a more >>> formal adoption, it wasn't entirely clear if this should be in the QUIC wg. >>> >>> (I am also CC'ing the HTTP wg via Lucas Pardue, who thought this would >>> somewhat concern them as well) >>> >>> To recap, qlog consists of two parts: >>> 1) the main schema, which is protocol agnostic and mostly defines the >>> serialization and container format [1] >>> 2) the QUIC and HTTP/3 specific events [2] >>> >> >> Yes sorry HTTP folks blame me for your additional email traffic. The >> reason I thought the discussion on qlog was pertinent to the HTTP WG is >> because one of the major places I've found benefit is in analyzing stream >> multiplexing using qvis. This has particularly been useful for developing >> an implementation of Extensible Priorities in an HTTP/3 stack. The most >> mature way to get qlog for HTTP/2 stacks would be to define qlog schemas >> for TCP, TLS and HTTP/2. >> >> There are potentially other application mappings. As was discussed at the >> IETF 109 session, I think congestion control is going to be something that >> benefits from logging and tooling. Is there an interest in making qlog work >> the same for a CCA across TCP and QUIC? I suspect that might drive some >> opinion of what to do here. >> >> >>> I can see roughly 3 main options and would like additional feedback on >>> which people want: >>> A) Adopt both in QUIC wg for now, bring them to ~full maturity for QUIC >>> and H3, and then see if/how to generalize later (it seemed to me most were >>> leaning to this side last week) >>> B) Adopt document [2] in QUIC wg and find another place for [1], either >>> in an existing wg or a new one via BOF by IETF 110 (what happens if that >>> fails though?) >>> C) Find an existing wg or do a BOF for both [1] and [2] together by IETF >>> 110 (not sure this has enough traction outside of QUIC wg?) >>> >>> >> Option A seems the most pragmatic given where we are. But the more I >> think about things, the more concerned I get that a focus on QUIC stifles >> the innovation of other qlog use cases simply because they fall out of the >> scope of permitted discussion. So far, the main schema discussion has >> rightly focused on more operational concerns like serialization format, we >> should also let people with interest and expertise in this area flourish if >> possible. Finally, I also have a concern that the combined QUIC & HTTP/3 >> schema becomes difficult to manage once we hand the reigns of HTTP/3 back. >> >> So I don't have a personal strong decision yet. But I'd like to consider >> an Option D that splits the QUIC & HTTP/3 schema, with each WG getting >> first refusal for adoption. Meanwhile, we continue to discuss the main >> schema. >> >> Cheers >> Lucas >> >>
