Subject: Fwd: New Version Notification for draft-huitema-quic-ts-05.txt

From: Christian Huitema <[email-masked]>
Date: Wed, 17 Mar 2021 18:14:41 -0700

This revision of the timestamp draft addresses recent comments by Dmitri 
Tikhonov, Martin Thomson and Ian Swett. As I mentioned during the IETF 
meeting, this draft is implemented in picoquic and lsquic, and we have 
demonstrated interoperability. I would like to see it adopted by the 
working group.

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-huitema-quic-ts-05.txt
Date: 	Wed, 17 Mar 2021 18:06:55 -0700
From: 	[email-masked]
To: 	Christian Huitema <[email-masked]>

A new version of I-D, draft-huitema-quic-ts-05.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-ts
Revision: 05
Title: Quic Timestamps For Measuring One-Way Delays
Document date: 2021-03-17
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-huitema-quic-ts-05.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-05
Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-05

Abstract:
The TIMESTAMP frame can be added to Quic packets when one way delay
measurements are useful. The timestamp is set to the number of
microseconds from the beginning of the node's epoch to the time at
which the packet is sent. The draft defines the "enable_timestamp"
transport parameter for negotiating the use of this extension frame,
and the TIMESTAMP frame.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 17 Mar 2021 20:44:41 -0700

Thanks Christian.

I have some comments.

1. Abstract - QUIC is not used as an acronym.

2. Introduction: 
 An example would be the Low Extra Delay Background Transport (LEDBAT)
   [RFC6817 <https://tools.ietf.org/html/rfc6817>] which uses variations in transmission delay ….

I think you meant to say queuing delay here.

3. Introduction:
Using 1WD solves these
   issues.  Similar argument can be made for most delay-based
   algorithms.

I disagree that it can be said for most delay based CCAs. LEDBAT++ and Receive LEDBAT don’t use OWD.
For delay based algorithms, I am of the opinion that we should consider RTT (instead of 1WD) as we should also be mindful of the ACK traffic on the return path, if it is congested and we can do that by slowing down the sender. 

4. Section 2.1
2 or 3 MUST NOT send these frames if the other
   peer does not announce advertise

Typo  - either announce or advertise

5. Section 2.2

Following successful sending negotiation…

“Sending” is probably extraneous here.

6. Section 2.2
 They MAY be sent either before or after the ACK frame.

I think replacing “sent” with “added” would be better here. 

7. Section 2.3
For congestion control, TIMESTAMP frames are treated like ACK frames.

I don’t understand why this should be the case. I think TIMESTAMP frame should be guarded by CC limits.

8. Section 2.3
The same applies to packets
   containing only TIMESTAMP frames

For my curiosity, when do you think packets containing only TS frame would be useful? Also, based on Section 2.6, such a packet wouldn’t be used for 1wd computation.
Is it better to prohibit such a packet?

9. Section 2.6
 latest_1wd = timestamp - send_time_of_largest_acked - phase_shift

I think ack_delay should also be subtracted to remove the processing delay from the 1wd.

Alternatively, one could change how timestamp is encoded. The current text in Section 2.3 says 

"The timestamp encodes the number of microseconds since the beginning
   of the epoch, as measured by the peer at the time at which the packet
   is sent.” 

This could be changed to “time at which the packet was received by the peer”. That would eliminate the processing delay.

Thats all for now. Will let you know if something else comes to mind.

Thanks
Vidhi

> On Mar 17, 2021, at 6:14 PM, Christian Huitema <[email-masked]> wrote:
> 
> This revision of the timestamp draft addresses recent comments by Dmitri Tikhonov, Martin Thomson and Ian Swett. As I mentioned during the IETF meeting, this draft is implemented in picoquic and lsquic, and we have demonstrated interoperability. I would like to see it adopted by the working group.
> 
> -- Christian Huitema
> 
> 
> 
> From:	[email-masked] <mailto:[email-masked]>
> To:	Christian Huitema <[email-masked]> <mailto:[email-masked]>
> 
> 
> URL: https://www.ietf.org/archive/id/draft-huitema-quic-ts-05.txt <https://www.ietf.org/archive/id/draft-huitema-quic-ts-05.txt>
> Status: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/ <https://datatracker.ietf.org/doc/draft-huitema-quic-ts/>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts <https://datatracker.ietf.org/doc/html/draft-huitema-quic-ts>
> Htmlized: https://tools.ietf.org/html/draft-huitema-quic-ts-05 <https://tools.ietf.org/html/draft-huitema-quic-ts-05>
> Diff: https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-05 <https://www.ietf.org/rfcdiff?url2=draft-huitema-quic-ts-05>
> 
> Abstract:

---

From: Christian Huitema <[email-masked]>
Date: Wed, 17 Mar 2021 21:39:31 -0700

Thanks for the review, Vidhi.

A few comments in line.

> 1. Abstract - QUIC is not used as an acronym.
Yes. I don't use it as an acronym either. But I realize I wrote "Quic" 
instead of "QUIC". I wonder whether WG members have strong feelings 
about that.
> I think you meant to say queuing delay here.
No. I do mean transmission delay, because that's what the LEDBAT 
implementations use. There is an assumption that the variations of 
transmission delays correspond to variations of queuing delays, but 
that's just an hypothesis.
> For delay based algorithms, I am of the opinion that we should consider RTT (instead of 1WD) as we should also be mindful of the ACK traffic on the return path, if it is congested and we can do tha…

Well, I am on the opinion that LEDBAT++ should use one-way-delay when 
timestamps are available. It does fallback to RTT when timestamps are 
not available, but that's a fallback mechanism, not a design goal. In 
fact, section 4.5 of the LEDBAT++ draft 
(https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5) 
acknowledges that using RTT instead of one-way-delays "can lead to 
unnecessary slowdowns". The text in that section goes on explaining how 
they mitigate that, but using one-way-delays would definitely be cleaner 
than relying on mitigations.

And yes, it is worth monitoring congestion on the return path, but the 
proper response there is not to "do as if the direct path was 
congested." Other mechanisms are available, such as sending fewer ACKs 
or fewer data on that path.

> Typo  - either announce or advertise
Yes. Will fix that in the next iteration.
> “Sending” is probably extraneous here.
Yes. Will fix that too.
> I think replacing “sent” with “added” would be better here.
Yes.
> I don’t understand why this should be the case. I think TIMESTAMP frame should be guarded by CC limits.

This text is based on a suggestion by Ian Swett, `The draft says 
"TIME_STAMP frames are not ack-eliciting. Their loss does not require 
retransmission." I (Ian)  believe the draft should clarify whether 
adding a TIME_STAMP frame to a packet causes it to count as in-flight as 
PADDING would, or not in-flight as an ACK frame would. I (Ian) believe 
treating it like an ACK frame is the ideal option, personally.`

The whole point of adoption by the WG is that we can discuss this issue 
in the WG.

> Is it better to prohibit such a packet?

I would rather not introduce another failure condition. I have at least 
one use case, measuring one way delays on seldom used paths in a 
multi-path configuration. It is not exactly compelling, but at the same 
time there is no strong reason to prohibit it.

> This could be changed to “time at which the packet was received by the peer”. That would eliminate the processing delay.

Good point.  I think the computation should mention the ACK delay.

I like the timestamp being exactly the time at which the packet is sent, 
because that keeps the specification very clean. It also helps scenarios 
in which the timestamp is used with something else than an ACK -- 
challenge response comes to mind, but there are probably other 
possibilities when composing timestamps with other frames. Maybe 
composing timestamps and datagrams in real time applications.

> Thats all for now. Will let you know if something else comes to mind.
Thanks for the feedback!

-- Christian Huitema

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 18 Mar 2021 05:11:33 +0000

HI Christian,

Thanks for sharing the idea. I don't profess to be a CC guru but the I-D
and the discussion made me wonder something. Now that you decoupled the
timestamp from ACK, how coupled are the remaining elements? There's a frame
with a field where the value is unilaterally set, some calculations based
on the values, and some choices about how to pack.

TIMESTAMP reminds me a little of DATAGRAM. So my curve ball thought is that
one could define a container frame for the transport layer signalling that
is unreliable and not flow or congestion controlled. We solve the problem
once. Then different use cases, like 1WD, could just define a parameter in
a container, along with some tips on how/when to packetize it.

I can predict some downsides with that approach but curious if others think
that make QUIC more pluggable.

Cheers
Lucas

On Thu, 18 Mar 2021, 04:40 Christian Huitema, <[email-masked]> wrote:

> > For delay based algorithms, I am of the opinion that we should consider
> RTT (instead of 1WD) as we should also be mindful of the ACK traffic on the
> return path, if it is congested and we can do that by slowing down the
> sender.
>
> (
> https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5)
>
> > For my curiosity, when do you think packets containing only TS frame
> would be useful? Also, based on Section 2.6, such a packet wouldn’t be used
> for 1wd computation.
> > This could be changed to “time at which the packet was received by the
> peer”. That would eliminate the processing delay.
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 17 Mar 2021 22:23:03 -0700

> a container, along with some tips on how/when to packetize it.

I am not sure I follow the "container" idea. We could certainly have a 
property attached to a frame type -- we do that today. Or, we could have 
a special frame type reserved as a marker that "the next frame does not 
require an ACK".

As for CC effects, this is really all on the sender side, so there is 
little benefit in a fancy encoding that tells that to the peer. In fact, 
peers do not even negotiate which CC algorithm they use, and it is quite 
common for client and server to use different ones.

> that make QUIC more pluggable.

You do need some additional code before sending or accepting a new frame 
type, so I am not too sure about the "pluggability" impact.

-- Christian Huitema

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 17 Mar 2021 23:03:04 -0700

> Yes. I don't use it as an acronym either. But I realize I wrote "Quic" instead of "QUIC". I wonder whether WG members have strong feelings about that.

It would be good to be consistent. I’d prefer it to be acronym (QUIC).

> No. I do mean transmission delay, because that's what the LEDBAT implementations use. There is an assumption that the variations of transmission delays correspond to variations of queuing delays, but that's just an hypothesis.

I am confused. RFC 6817 says the below which points to queuing delay varying while other delays remaining constant-ish.

“End-to-end delay can be decomposed into transmission (or
   serialization) delay, propagation (or speed-of-light) delay, queueing
   delay, and processing delay.  On any given path, barring some noise,
   all delay components except for queueing delay are constant.  To
   observe an increase in the queueing delay in the network, a LEDBAT
   sender separates the queueing delay component from the rest of the
   end-to-end delay, as described below.”

> Well, I am on the opinion that LEDBAT++ should use one-way-delay when timestamps are available. It does fallback to RTT when timestamps are not available, but that's a fallback mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5) acknowledges that using RTT instead of one-way-delays "can lead to unnecessary slowdowns”

Yes, and LEDBAT++ continues to say the below. For a delay based CC, how do you suggest the increased delay on reverse path (receiver to sender) be handled, if we don’t use RTT?
"but in practice this
   seems to benefit the workloads because bottleneck link can carry ACK
   traffic in the other direction for the competing flows."

> This text is based on a suggestion by Ian Swett, `The draft says "TIME_STAMP frames are not ack-eliciting. Their loss does not require retransmission." I (Ian)  believe the draft should clarify whether adding a TIME_STAMP frame to a packet causes it to count as in-flight as PADDING would, or not in-flight as an ACK frame would. I (Ian) believe treating it like an ACK frame is the ideal option, personally.`
> 
> The whole point of adoption by the WG is that we can discuss this issue in the WG.

Sorry, I am not too familiar with IETF procedures. Does this mean we can discuss in the next IETF meeting or something else?

Thanks,
Vidhi

> On Mar 17, 2021, at 9:39 PM, Christian Huitema <[email-masked]> wrote:
> 
> Yes. I don't use it as an acronym either. But I realize I wrote "Quic" instead of "QUIC". I wonder whether WG members have strong feelings about that.
>> 
>> 2. Introduction:
> No. I do mean transmission delay, because that's what the LEDBAT implementations use. There is an assumption that the variations of transmission delays correspond to variations of queuing delays, but that's just an hypothesis.
>> 
>> 3. Introduction:
>> Using 1WD solves these
> Well, I am on the opinion that LEDBAT++ should use one-way-delay when timestamps are available. It does fallback to RTT when timestamps are not available, but that's a fallback mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5) acknowledges that using RTT instead of one-way-delays "can lead to unnecessary slowdowns". The text in that section goes on explaining how they mitigate that, but using one-way-delays would definitely be cleaner than relying on mitigations.
> 
> And yes, it is worth monitoring congestion on the return path, but the proper response there is not to "do as if the direct path was congested." Other mechanisms are available, such as sending fewer ACKs or fewer data on that path.
> 
> 
>> 
>> 4. Section 2.1
> This text is based on a suggestion by Ian Swett, `The draft says "TIME_STAMP frames are not ack-eliciting. Their loss does not require retransmission." I (Ian)  believe the draft should clarify whether adding a TIME_STAMP frame to a packet causes it to count as in-flight as PADDING would, or not in-flight as an ACK frame would. I (Ian) believe treating it like an ACK frame is the ideal option, personally.`
> 
> The whole point of adoption by the WG is that we can discuss this issue in the WG.
> 
>> 8. Section 2.3
> I would rather not introduce another failure condition. I have at least one use case, measuring one way delays on seldom used paths in a multi-path configuration. It is not exactly compelling, but at the same time there is no strong reason to prohibit it.
> 
>> 
>> 9. Section 2.6
> I like the timestamp being exactly the time at which the packet is sent, because that keeps the specification very clean. It also helps scenarios in which the timestamp is used with something else than an ACK -- challenge response comes to mind, but there are probably other possibilities when composing timestamps with other frames. Maybe composing timestamps and datagrams in real time applications.
>

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 17 Mar 2021 23:11:02 -0700

>> Well, I am on the opinion that LEDBAT++ should use one-way-delay when timestamps are available. It does fallback to RTT when timestamps are not available, but that's a fallback mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5 <https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5>) acknowledges that using RTT instead of one-way-delays "can lead to unnecessary slowdowns”
> 

AccECN / L4S can definitely help on the reverse path but only if an implementation supports it. For the near future, we still need to address it and I think RTT helps with that.

-
Vidhi

> On Mar 17, 2021, at 11:03 PM, Vidhi Goel <vidhi_goel=[email-masked]> wrote:
> 
>>>    [RFC6817 <https://tools.ietf.org/html/rfc6817 <https://tools.ietf.org/html/rfc6817>>] which uses variations in transmission delay ….
>>> 
>> Well, I am on the opinion that LEDBAT++ should use one-way-delay when timestamps are available. It does fallback to RTT when timestamps are not available, but that's a fallback mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5 <https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5>) acknowledges that using RTT instead of one-way-delays "can lead to unnecessary slowdowns”
> 
>> On Mar 17, 2021, at 9:39 PM, Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>    [RFC6817 <https://tools.ietf.org/html/rfc6817 <https://tools.ietf.org/html/rfc6817>>] which uses variations in transmission delay ….
>>> 
>> Well, I am on the opinion that LEDBAT++ should use one-way-delay when timestamps are available. It does fallback to RTT when timestamps are not available, but that's a fallback mechanism, not a design goal. In fact, section 4.5 of the LEDBAT++ draft (https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5 <https://tools.ietf.org/html/draft-irtf-iccrg-ledbat-plus-plus-01#section-4.5>) acknowledges that using RTT instead of one-way-delays "can lead to unnecessary slowdowns". The text in that section goes on explaining how they mitigate that, but using one-way-delays would definitely be cleaner than relying on mitigations.
>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 17 Mar 2021 23:57:40 -0700

> It would be good to be consistent. I’d prefer it to be acronym (QUIC).

The transport specification states clearly:

QUIC: The transport protocol described by this document. QUIC is a name, 
not an acronym.

What you want is using the all capital name "QUIC", rather than my 
deviant spelling "Quic". I personally feel that as QUIC is a name, it 
should be written the way we spell other names like "John" or "Eric". 
But then, all the QUIC drafts use the all-capitals spelling, so I am not 
going to argue too long for this one...

>     end-to-end delay, as described below.”
Again, this is an hypothesis based on theory. Increase in one way delays 
are well correlated with queuing delay, but what is measure is the delay 
from sending the packet to receiving it. I am accustomed to describing 
that as the "transmission delay", but you are right that the term is 
often used as in RFC 6817, to describe the "serialization" delay. 
"End-to-end" delay might be the more appropriate term to describe what 
the nodes actually measure.
>     traffic in the other direction for the competing flows."
This is explaining that they err on the side of caution, which is OK 
because LEDBAT is for low priority traffic anyhow. But if you remove the 
"low priority" property, this is not OK.
> Sorry, I am not too familiar with IETF procedures. Does this mean we can discuss in the next IETF meeting or something else?

Mailing list, github, interim, IETF... The way we do things.

-- Christian Huitema

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 18 Mar 2021 00:54:55 -0700

> Mailing list, github, interim, IETF... The way we do things.

Ah, ok. Thats what I did :-)
If we don’t include TIMESTAMP in bytes_in_flight, I worry if increasing on-wire bytes in flight without reflecting at the host could cause the host to cause congestion inadvertently and not react to it if it is only sending ACKs + TIMESTAMPs.

OTOH, if it was like PADDING, it would help to avoid congestion and we wouldn’t send TIMESTAMP when out of CC limit. In that case, we would send only pure ACKs (without TS frame)

What do you think?

Thanks,
Vidhi
> On Mar 17, 2021, at 11:57 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> QUIC: The transport protocol described by this document. QUIC is a name, not an acronym.
> 
> What you want is using the all capital name "QUIC", rather than my deviant spelling "Quic". I personally feel that as QUIC is a name, it should be written the way we spell other names like "John" or "Eric". But then, all the QUIC drafts use the all-capitals spelling, so I am not going to argue too long for this one...
> 
>> 
>>>> 2. Introduction:
> Again, this is an hypothesis based on theory. Increase in one way delays are well correlated with queuing delay, but what is measure is the delay from sending the packet to receiving it. I am accustomed to describing that as the "transmission delay", but you are right that the term is often used as in RFC 6817, to describe the "serialization" delay. "End-to-end" delay might be the more appropriate term to describe what the nodes actually measure.
>> 
>> 
>>>> 3. Introduction:
>>>> Using 1WD solves these
> This is explaining that they err on the side of caution, which is OK because LEDBAT is for low priority traffic anyhow. But if you remove the "low priority" property, this is not OK.
>> 
>>>> 7. Section 2.3

---

From: Matt Joras <[email-masked]>
Date: Thu, 18 Mar 2021 09:06:30 -0600

> a special frame type reserved as a marker that "the next frame does not

I think what Lucas is suggesting, and has been suggested before, is
that we are likely to have many frames which have similar
transmission/loss/transport handling properties, so why not have a
generic frame we build atop for some extensions?

I would hope we don't take this direction, as we did not take this
direction in the "core" frames in the specification, many of which
have identical transport handling. The design of QUIC v1, IMO,
encourages more frames rather than fewer. It is very easy for us to
add new frames. Putting "similar" frames all on a generic frame's
framework doesn't really save us time in specifying the semantics of
that frame. At best it might save some implementation complexity, but
I would argue that such concerns can be addressed by the
implementations. For example, mvfst has the notion of a generic
"simple frame" which is one which is not retransmitted and there are
not expected to be a great many of them. Many extension frames will
likely be implemented using this implementation-specific framework,
and I would expect other implementations to have their own techniques
for optimizing the implementation of new frames. And as Christian
notes an implementation will always have to implement the semantics of
what the frame actually does anyway.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 18 Mar 2021 17:42:36 +0000

Hey Matt,

> what the frame actually does anyway.

You've done a much better job of articulating the idea that I had.

My suggestion was motivated by an observation that people designing
extensions might have to revisit the same questions over and over: "does
this frame need to be ack-eliciting, can a packet of pure frames be sent,
does the frame behave like that one or this one, or does it need to be a
little special". This is all in the context of how the frame affects the
transport, not the how the frame enables the extension. We're a young WG,
and there are not many design patterns or cookie-cutter examples to help
people focus on the problem they are solving rather than getting bogged
down by problems they might cause. There is institutional knowledge in the
WG and I'd love for us to find a way of capturing that so that others can
benefit. The mvfst example sounds great, you optimized for implementers. A
concrete frame type might be too far. But maybe we could start thinking
about some format to build upon the advice already in the 19.21 of the
transport doc. That might come with time as we learn but maybe some people
already have some ideas...

Cheers
Lucas

[1] https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-19.21

---

From: Christian Huitema <[email-masked]>
Date: Thu, 18 Mar 2021 12:09:51 -0700

> [1] https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-19.21

I suppose that you mean the part that says "Extension frames MUST be 
congestion controlled and MUST cause an ACK frame to be sent. The 
exception is extension frames that replace or supplement the ACK frame. 
Extension frames are not included in flow control unless specified in 
the extension." The TIMESTAMP frame falls in this "supplement the ACK 
frame" category.

What we have now is simple: just explain in the spec that the extension 
is treated as an extension of the ACK. I am not sure that we know enough 
to specify a container format or any such superstructure. Consider for 
example the ACK_MP proposals, in which a single packet could carry 
several ACK_MP. There are good reasons to add a TIMESTAMP to such 
packets, but you need only one of those for several ACK_MP. It would be 
very easy to define "container" formats that break in such unanticipated 
cases.

-- Christian Huitema

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 18 Mar 2021 19:15:43 +0000

> very easy to define "container" formats that break in such unanticipated

That's an excellent reason not to overcomplicate things and stick to
independent frame types like TIMESTAMP.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Mar 2021 07:47:31 -0500

Hi, Lucas,

> already have some ideas...

I was just talking about work like this in the Cellar working group
yesterday.

In the Days before CoViD-19 (IETF 106), we talked in TSVAREA (
https://datatracker.ietf.org/doc/minutes-106-tsvarea/) about two ideas that
seemed to have traction:

   - running a couple of QUIC Dispatch sessions for all the extensions that
   were stacked up behind the core QUIC documents (
   https://datatracker.ietf.org/wg/quic/documents/ shows 11 docs adopted,
   28 not yet adopted), so that proposals could get the benefit of guidance
   from the QUIC community without using QUIC working group time, and
   - doing something to give guidance to implementers, before QUIC is like
   SIP or TCP with dozens of documents for people to read and grok (see
   https://tools.ietf.org/html/rfc7414 for TCP,
   https://tools.ietf.org/html/rfc5411 for SIP, but those aren't perfect
   models, because the number of specifications was so large before anyone
   tried to organize guidance).

The first suggestion is up to you and Matt, of course, but the second
section seems like something we could start on now.

Best,

Spencer

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 23 Mar 2021 19:09:18 +0000

Hey Spencer,

On Tue, Mar 23, 2021 at 12:47 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> https://datatracker.ietf.org/doc/minutes-106-tsvarea/) about two ideas
> that seemed to have traction:
>
>    - running a couple of QUIC Dispatch sessions for all the extensions
>    that were stacked up behind the core QUIC documents (
> Our intent is that the recharter gives us a clearer formal statement about
what is, and is not, in scope for the QUIC WG. I hope things are naturally
more clear than they were during IETF 106. We can of course field ideas and
help people figure out where work might best belong, or best be broken
apart into reusable transport extensions and application-specific things
that belong elsewhere. The important thing is to get people to the most
appropriate place in a speedy manner.

For the uncertainty of doubt, the list of I-Ds in "Related Internet-Drafts"
is populated by a regex that looks for "quic". It really is as simple as
that. Unfortunately it means that some documents get listed when our new
charter would mark them out of scope. Or even when a doc author has no
intention to pitch the idea into a WG. I skimmed over the drafts in the
current list and put them in my sorting hat. I won't list them by name
because I'm not talking authoritatively about them. Here's my take:

* 6 are application mappings
* 7 are transport extensions
* 2 are maintenance-oriented
* 2 are non-QUIC extensions
* 7 are multipath-related
* the remainder are loosely tied to QUIC

Several of the items that are possibly in-scope are already in hand.

>
>    - doing something to give guidance to implementers, before QUIC is
>    like SIP or TCP with dozens of documents for people to read and grok (see
> Good idea and we're open to suggestions about effective ways to do this.
We've already been doing a bit of this on the QUIC WG base-drafts
repository I think https://quicwg.org/ is possibly a good place to
consolidate different information and pointers about all things QUIC.
Capturing information in an RFC seems to invite going stale immediately,
and is maybe a bit rigid for the types of things people might find useful
to know about.

Cheers,
Lucas