[{"author": "Richard Scheffenegger", "text": "

should there be audio yet?

", "time": "2023-03-30T00:31:40Z"}, {"author": "Robin Marx", "text": "

I'm also getting no audio

", "time": "2023-03-30T00:31:47Z"}, {"author": "Matt Joras", "text": "


", "time": "2023-03-30T00:31:54Z"}, {"author": "Mark Thomas", "text": "

No audio here either

", "time": "2023-03-30T00:31:57Z"}, {"author": "Matt Joras", "text": "

meetecho: we have no remote audio apparently

", "time": "2023-03-30T00:32:03Z"}, {"author": "Ira McDonald", "text": "

No audio

", "time": "2023-03-30T00:32:04Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "

No audio here

", "time": "2023-03-30T00:32:17Z"}, {"author": "Lorenzo Miniero", "text": "

Are mics turned on?

", "time": "2023-03-30T00:32:17Z"}, {"author": "Chris Lemmons", "text": "

I assumed people hadn't started talking. Oops.

", "time": "2023-03-30T00:32:18Z"}, {"author": "Richard Scheffenegger", "text": "

we are at the note-well, so I assume there should be some talking...

", "time": "2023-03-30T00:32:44Z"}, {"author": "Lorenzo Miniero", "text": "

It should be ok now

", "time": "2023-03-30T00:32:45Z"}, {"author": "Matt Joras", "text": "

yeah mica EW ON

", "time": "2023-03-30T00:32:47Z"}, {"author": "Richard Scheffenegger", "text": "


", "time": "2023-03-30T00:32:52Z"}, {"author": "Chris Lemmons", "text": "

We hear!

", "time": "2023-03-30T00:32:55Z"}, {"author": "Robin Marx", "text": "


", "time": "2023-03-30T00:32:55Z"}, {"author": "Mark Thomas", "text": "


", "time": "2023-03-30T00:32:56Z"}, {"author": "Ira McDonald", "text": "


", "time": "2023-03-30T00:32:56Z"}, {"author": "Richard Scheffenegger", "text": "


", "time": "2023-03-30T00:32:56Z"}, {"author": "Matt Joras", "text": "


", "time": "2023-03-30T00:33:02Z"}, {"author": "Christian Huitema", "text": "

Nope. Not desiggned to be read by old folks.

", "time": "2023-03-30T00:33:26Z"}, {"author": "Zaheduzzaman Sarker", "text": "

Good morning from JST zone!!!

", "time": "2023-03-30T00:33:30Z"}, {"author": "Robin Marx", "text": "

Good middle of the night from Belgium ;)

", "time": "2023-03-30T00:34:49Z"}, {"author": "Robin Marx", "text": "

I'll take some notes

", "time": "2023-03-30T00:35:02Z"}, {"author": "Richard Scheffenegger", "text": "

@zahed - let me tell you that even on the 5th day, remote participation in JST tz is still not easy despite my efforts with massive lights to get my cicadian cycle adjusted...

", "time": "2023-03-30T00:35:08Z"}, {"author": "Robin Marx", "text": "

Though given the hour, not sure how good they'll be ;)

", "time": "2023-03-30T00:35:12Z"}, {"author": "Robin Marx", "text": "


", "time": "2023-03-30T00:35:32Z"}, {"author": "Martin Thomson", "text": "

I notice that the Alibaba editors on the MP draft only have the latin transliteration of their names on the draft. Has anyone asked if they want to use their actual names?

", "time": "2023-03-30T00:41:00Z"}, {"author": "Lucas Pardue", "text": "


", "time": "2023-03-30T00:41:10Z"}, {"author": "Zaheduzzaman Sarker", "text": "

@Richard Scheffenegger even being in the JST tz is not proving to be that helpful to me either :-(

", "time": "2023-03-30T00:42:45Z"}, {"author": "Momoka Yamamoto", "text": "

@MT You mean to use Chinese characters? That would be cool.

", "time": "2023-03-30T00:43:30Z"}, {"author": "Lucas Pardue", "text": "

yeah, for example RFC 9218

", "time": "2023-03-30T00:43:47Z"}, {"author": "Martin Thomson", "text": "

@Momoka Yamamoto we have the technology, so we should do that

", "time": "2023-03-30T00:43:53Z"}, {"author": "Martin Thomson", "text": "

I'll open an issue

", "time": "2023-03-30T00:43:59Z"}, {"author": "Momoka Yamamoto", "text": "

RFC 9218 is the only example I currently know. But would be great if more people follow.

", "time": "2023-03-30T00:45:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I will check with them

", "time": "2023-03-30T00:46:32Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "

We can find many Chinese characters in contributor lists of RFCs.

", "time": "2023-03-30T00:47:13Z"}, {"author": "Martin Thomson", "text": "

Thanks Mirja

", "time": "2023-03-30T00:47:42Z"}, {"author": "Martin Thomson", "text": "


", "time": "2023-03-30T00:47:51Z"}, {"author": "Martin Thomson", "text": "

@\u5c71\u672c\u548c\u5f66 I can't type your name, but I can copy and paste it :)

", "time": "2023-03-30T00:48:53Z"}, {"author": "Christian Huitema", "text": "

Big merit of the \"loose\" model is that code becomes much simpler.

", "time": "2023-03-30T00:49:00Z"}, {"author": "Martin Thomson", "text": "

The loose model is simpler to implement yes.

", "time": "2023-03-30T00:49:12Z"}, {"author": "Martin Thomson", "text": "

Was there a conclusion?

", "time": "2023-03-30T00:49:16Z"}, {"author": "Martin Thomson", "text": "

That is not the right error code. Make a new one.

", "time": "2023-03-30T00:49:57Z"}, {"author": "Christian Huitema", "text": "

+1 Martin. Having a specific error code will make debugging easier.

", "time": "2023-03-30T00:51:30Z"}, {"author": "Matt Joras", "text": "

As an individual, +1 more error more better

", "time": "2023-03-30T00:52:03Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "


", "time": "2023-03-30T00:52:04Z"}, {"author": "Martin Thomson", "text": "

An error code that is never used is also totally fine

", "time": "2023-03-30T00:52:41Z"}, {"author": "David Schinazi", "text": "

It wouldn't be IETF if we didn't rathole on the simplest issue in the list

", "time": "2023-03-30T00:54:37Z"}, {"author": "Kazuho Oku", "text": "

Looked for precedence, I think we say in the ack-frequency draft that if min-ack-delay and max-ack-delay contradicts to each other, we raise PROTOCOL_VIOLATION.

", "time": "2023-03-30T00:55:12Z"}, {"author": "Kazuho Oku", "text": "

So if we think transport-parameter-related errors have to use TRANSPORT_PARAMETER_ERROR, then we have to change the ack-frequency draft.

", "time": "2023-03-30T00:56:36Z"}, {"author": "Lucas Pardue", "text": "

yes sounds liek we should raise an issue on ack frequency

", "time": "2023-03-30T00:56:47Z"}, {"author": "Matt Joras", "text": "

Indiidually I like MT's idea -- we already have a cheap extension point in frames

", "time": "2023-03-30T00:58:37Z"}, {"author": "Christian Huitema", "text": "

No. Unknown vaue is a protocol error!

", "time": "2023-03-30T01:00:39Z"}, {"author": "Christian Huitema", "text": "

+1 Martin's idea.

", "time": "2023-03-30T01:00:51Z"}, {"author": "Martin Thomson", "text": "

I think that any draft SHOULD not say SHOULD, but instead describe in more detail what happens when different choices are made, though I think that Ian's point is well made

", "time": "2023-03-30T01:06:36Z"}, {"author": "Martin Thomson", "text": "

Is there any way we might use something like the IMMEDIATE_ACK frame, or is that PATH_CHALLENGE?

", "time": "2023-03-30T01:09:03Z"}, {"author": "Martin Thomson", "text": "

In case you want to measure path RTT

", "time": "2023-03-30T01:09:14Z"}, {"author": "Christian Huitema", "text": "

Path Challenge does not cut it, because Path Response could be sent on any path

", "time": "2023-03-30T01:09:44Z"}, {"author": "Vidhi Goel", "text": "

This is a tricky issue. I dont think that RTT estimation should be left to CC impl

", "time": "2023-03-30T01:09:47Z"}, {"author": "Christian Huitema", "text": "

Vidhi, the naive implementation will work just fine for example for Hystart, or Ledbat, or BBR.

", "time": "2023-03-30T01:10:50Z"}, {"author": "Martin Thomson", "text": "

@Christian Huitema yeah, that's a problem. Maybe an ACK_THIS_ON_A_SPECIFIC_PATH frame then, which would contain a path ID

", "time": "2023-03-30T01:11:03Z"}, {"author": "Christian Huitema", "text": "

But if you want to do that, you also want time stamps so you can estimate one way delay variations...

", "time": "2023-03-30T01:12:05Z"}, {"author": "Martin Thomson", "text": "

That would let you estimate cross-path RTT

", "time": "2023-03-30T01:12:10Z"}, {"author": "Martin Thomson", "text": "

the timestamp thing could be orthogonal, because the ACK is independent of what caused it to happen

", "time": "2023-03-30T01:12:51Z"}, {"author": "Christian Huitema", "text": "

Path status repeat is pretty much the same issue as repeating control flow frame. You do not repeat them, you send a new version with current values.

", "time": "2023-03-30T01:13:24Z"}, {"author": "Vidhi Goel", "text": "

If measured RTT is smaller than actual, wouldnt CC cause more buffer occupancy?

", "time": "2023-03-30T01:13:36Z"}, {"author": "Christian Huitema", "text": "

No. That's widely tested in e.g. staellite links with terrestrial return.

", "time": "2023-03-30T01:14:11Z"}, {"author": "Martin Thomson", "text": "

I don't think so. Smaller RTT estimates only matter when things change

", "time": "2023-03-30T01:14:26Z"}, {"author": "Martin Thomson", "text": "

That is, a drop in RTT might cause an increase in send rate in some CC

", "time": "2023-03-30T01:14:44Z"}, {"author": "Martin Thomson", "text": "

I agree with @Christian Huitema, unless the proponents can somehow argue that things would be worse if this is not in the core draft, but this seems entirely optional

", "time": "2023-03-30T01:16:45Z"}, {"author": "Vidhi Goel", "text": "

Sure, but when flows with different RTTs compete, there is an unequal share between short vs long RTT. So, different impl might make flows with same actual RTT look like they have different RTT and hence different link share

", "time": "2023-03-30T01:18:17Z"}, {"author": "Christian Huitema", "text": "

And that's fine. Just like there will be a difference with flows that naturally have shorter RTT than others.

", "time": "2023-03-30T01:19:07Z"}, {"author": "Martin Thomson", "text": "

Why is the reordering threshold (8) and not (i) ?

", "time": "2023-03-30T01:20:42Z"}, {"author": "Matt Joras", "text": "

there was an issue about that IIRC?

", "time": "2023-03-30T01:20:55Z"}, {"author": "Christian Huitema", "text": "

I would absolutely argue for (i). Suppose your RTT is 40 minutes (Earth to Mars)...

", "time": "2023-03-30T01:21:34Z"}, {"author": "Alan Frindell", "text": "

Rename the quic wg to 'varint'?

", "time": "2023-03-30T01:22:04Z"}, {"author": "Christian Huitema", "text": "


", "time": "2023-03-30T01:22:14Z"}, {"author": "Christian Huitema", "text": "

I love nothing

", "time": "2023-03-30T01:26:18Z"}, {"author": "Vidhi Goel", "text": "

Rephrase the text to say enough acks instead of a specific number

", "time": "2023-03-30T01:27:05Z"}, {"author": "Martin Thomson", "text": "

Agree with @Matt Joras I would prefer to have this be something like \"performance might suffer if fewer ACK frames are sent, with worse performance as ACKs are sent less often relative to the RTT. sending fewer than one ACK per RTT can have serious consequences for performance. sending at least several ACKs on each RTT (2-4) is likely to be necessary for adequate performance. connections with extremely low RTT and stable path delay might be able to use fewer acknowledgments\"

", "time": "2023-03-30T01:31:55Z"}, {"author": "Martin Thomson", "text": "

... or something like that

", "time": "2023-03-30T01:32:03Z"}, {"author": "Christian Huitema", "text": "

I agree with Martin.

", "time": "2023-03-30T01:33:46Z"}, {"author": "David Schinazi", "text": "

+1 to MT

", "time": "2023-03-30T01:34:35Z"}, {"author": "Gorry Fairhurst", "text": "

Sending fewer that one ACK per RTT is a really odd document.

", "time": "2023-03-30T01:34:49Z"}, {"author": "Christian Huitema", "text": "

One per RTT is self-stabilizing, since the RTT in practice includes the delay to the ACK

", "time": "2023-03-30T01:35:29Z"}, {"author": "Martin Thomson", "text": "

@Gorry Fairhurst I agree, but can we not agree that the only effect is that performance tanks really badly?

", "time": "2023-03-30T01:35:44Z"}, {"author": "John Border", "text": "

I am little concerned about one for longer RTTs but the suggestion of tying it to a general discussion of the length of the RTT works.

", "time": "2023-03-30T01:35:56Z"}, {"author": "Matt Joras", "text": "

+1 MT

", "time": "2023-03-30T01:36:18Z"}, {"author": "Gorry Fairhurst", "text": "

@Martin: I'm unsure.... have you got data on that from reverse path congetsion scenarios?

", "time": "2023-03-30T01:37:15Z"}, {"author": "Robin Marx", "text": "

Ok, belgium is not a GREAT place, but to call if awful... ;)

", "time": "2023-03-30T01:38:03Z"}, {"author": "David Schinazi", "text": "

I was wondering which country he was badmouthing

", "time": "2023-03-30T01:38:23Z"}, {"author": "Martin Thomson", "text": "

@Gorry Fairhurst you are concerned about stability of the CC? Because my expectation is that the ACK rate will be stable. I suspect that changing from 10/RTT to 0.5/RTT might be bad...

", "time": "2023-03-30T01:38:31Z"}, {"author": "David Schinazi", "text": "

I agree with Lucas about slides being much more fun when Robin makes them

", "time": "2023-03-30T01:38:43Z"}, {"author": "Robin Marx", "text": "

Nice to hear you're a \"Robin's slides enthousiast\" as well David

", "time": "2023-03-30T01:39:11Z"}, {"author": "Mike Bishop", "text": "

Robin Marx said:


Ok, belgium is not a GREAT place, but to call if awful... ;)


I quite enjoyed my time in Belgium. Don't know what he's referring to.

", "time": "2023-03-30T01:39:33Z"}, {"author": "Robin Marx", "text": "

He mainly meant I'm in an awful timezone for doing a coherent presentation

", "time": "2023-03-30T01:40:09Z"}, {"author": "Mirja K\u00fchlewind", "text": "

was that ever a requirement to be coherent...? ;-)

", "time": "2023-03-30T01:40:51Z"}, {"author": "Robin Marx", "text": "

@mirja: this explains many things...

", "time": "2023-03-30T01:41:36Z"}, {"author": "Mirja K\u00fchlewind", "text": "

happy to help

", "time": "2023-03-30T01:42:20Z"}, {"author": "Martin Thomson", "text": "

@Lucas Pardue why not use JSON-LD?

", "time": "2023-03-30T01:43:57Z"}, {"author": "Gorry Fairhurst", "text": "

@Martin Basically yes - the protocol expects feedback, and if we reduce ACKs down to one per RTT then we might be able to still track RTT variation (including from return path congestion); if we have just one ACK per RTT and a window of many 100's of packets, and we then have congestion from cross traffic etc on the return path, the actual path RTT changes, and failing to note that means we can't track RTT, etc. Making two ACKs per RTT gives robustness to loss and just avoids the weirdness - 3 or 4 per RTT actually is a reasonable shout for Internet paths ... I can quite believe that DC is different.

", "time": "2023-03-30T01:45:42Z"}, {"author": "Martin Thomson", "text": "


", "time": "2023-03-30T01:46:14Z"}, {"author": "Martin Thomson", "text": "

dynamic and scoped prefix binding FTW!

", "time": "2023-03-30T01:46:31Z"}, {"author": "Alan Frindell", "text": "

If we make a breaking schema change in qlog, are the tools out (looking at you qviz) there going to support both formats for some period of time? Or forever?

", "time": "2023-03-30T01:50:05Z"}, {"author": "Matt Joras", "text": "

@Gorry I think it's important to distinguish between the CC and the \"protocol\" for this discussion.QUIC already has to deal with insane RTT fluctuations that happen \"naturally\". It's not that weird to see cell networks that do nutty things where the RTT measurements can vary from 50ms to 2000ms over the course of a single burst.I don't think anyone disagrees about that we should have sensible recommendations _somewhere_ for what to do on typical Internet paths if you don't want performance to absolutely suck. The contention is where those recommendations should go and if they should be normative.

", "time": "2023-03-30T01:52:12Z"}, {"author": "Robin Marx", "text": "

@Alan: I can only speak for qvis, but there I would probably bite the bullet and support both options (but the older one would be slower, as I'd loop through old-style to change the strings before visualizing the new-style)

", "time": "2023-03-30T01:53:56Z"}, {"author": "Robin Marx", "text": "

wrt QPACK... we currently have no-one implementing the low-level events AFAIK and now explicit qvis support for them. I'm of the opinion they should be removed and only the high-level ones kept.

", "time": "2023-03-30T01:57:05Z"}, {"author": "Robin Marx", "text": "

*no explicit qvis support

", "time": "2023-03-30T01:57:24Z"}, {"author": "Martin Thomson", "text": "

RFC 3339 should do to indicate baseline, but also indicating the use of monotonic is fine

", "time": "2023-03-30T01:58:15Z"}, {"author": "Matt Joras", "text": "

note to self: mentioning clocks is a good way to wakeup the IETF crowd

", "time": "2023-03-30T01:59:19Z"}, {"author": "Ted Hardie", "text": "

@Martin I had forgotten about RFC 3339, thanks for the pointer.

", "time": "2023-03-30T01:59:56Z"}, {"author": "Christian Huitema", "text": "

What happens when you try to correlate sender and receiver traces with different clocks?

", "time": "2023-03-30T02:01:09Z"}, {"author": "Ira McDonald", "text": "

From IETF RATS - w/ CBOR details https://datatracker.ietf.org/doc/draft-birkholz-rats-epoch-markers/

", "time": "2023-03-30T02:01:10Z"}, {"author": "Matt Joras", "text": "

Christian: also, different senders ;)

", "time": "2023-03-30T02:01:29Z"}, {"author": "Matt Joras", "text": "

if you delegate sending to multiple hosts

", "time": "2023-03-30T02:01:40Z"}, {"author": "Christian Huitema", "text": "

I would be for declaring something like clock frequency, and also maybe an option for matching with NTP or GPS time.

", "time": "2023-03-30T02:02:24Z"}, {"author": "Gorry Fairhurst", "text": "

@ACKs (sorry it is still very early here and the chat RTT is rather high also): SHOULD 1/RTT is at least mostly known behaviour up to the point where congestion causes ACK loss: Regarding 1 ACK per RTT. A better way to explain this is that, unless you have absolutely perfect pacing of data and ACKS, half the RTTs will exhibit <1 ACK and the other half >1 ACK, that\u2019s a performance impact, because you'll be stalling half the time. Changing the ACK frequency does impact the CC behaviour: I am worried this can synchronise congestion in the return direction to the pattern of transmission in the forward direction, and strong CC synchronisation is worrying.

", "time": "2023-03-30T02:04:25Z"}, {"author": "Martin Thomson", "text": "

That RATS draft is probably over the top for our context

", "time": "2023-03-30T02:05:07Z"}, {"author": "Ira McDonald", "text": "

IETF RATS has done quite a lot of thinking about clocks/timestamps - here are the slides for that draft https://datatracker.ietf.org/doc/slides-116-rats-epoch-markers/

", "time": "2023-03-30T02:05:22Z"}, {"author": "Martin Thomson", "text": "

All I was suggesting was that we periodically drop in a wall-clock anchor from which subsequent items are relative to.

", "time": "2023-03-30T02:05:45Z"}, {"author": "Robin Marx", "text": "

@Christian: correlating logs with different clocks is one of the problems that led to this issue... I don't really see how it can be done if one of the logs doesn't have a proper \"real world\" reference timestamp (e.g., what quiche currently does). Do you feel this is even solvable?

", "time": "2023-03-30T02:05:55Z"}, {"author": "Robin Marx", "text": "

@Martin: that was clear to me and thanks for the suggestion. That's indeed not really possible at this time.

", "time": "2023-03-30T02:06:58Z"}, {"author": "Martin Thomson", "text": "

There will be small discrepancies if people use monotonic clocks that jump around a little, but they don't jump around that much; a periodical checkpoint (for NTP updates say) can correct for that in cases where precision matters

", "time": "2023-03-30T02:07:33Z"}, {"author": "Robin Marx", "text": "

@Ira: thanks for the input, wasn't aware of that, will take a look at it!

", "time": "2023-03-30T02:07:43Z"}, {"author": "Lucas Pardue", "text": "

persoanlly monotonic seems less jumpy that real-time clock

", "time": "2023-03-30T02:08:30Z"}, {"author": "Robin Marx", "text": "

Nice to see Marten is a \"Robin's slides enthousiast\" as well

", "time": "2023-03-30T02:09:44Z"}, {"author": "Martin Thomson", "text": "

no mention of Lamport clocks in the RATS draft

", "time": "2023-03-30T02:09:50Z"}, {"author": "Lucas Pardue", "text": "

why not use JSON-LD?


I'm not sure what that is in reference to

", "time": "2023-03-30T02:10:05Z"}, {"author": "Robin Marx", "text": "

@Lucas: for additional_schema

", "time": "2023-03-30T02:10:22Z"}, {"author": "Martin Thomson", "text": "

@Lucas Pardue you were listing schemas

", "time": "2023-03-30T02:10:44Z"}, {"author": "Martin Thomson", "text": "

the obvious solution there is namespacing, hence my mention of xmlns

", "time": "2023-03-30T02:11:06Z"}, {"author": "Lucas Pardue", "text": "

ohh sorry I read that as JSON line delimited, not linked data :faceplam:

", "time": "2023-03-30T02:11:09Z"}, {"author": "Lucas Pardue", "text": "

I'd like to avoid the namespace complications but maybe that concern is misplaced

", "time": "2023-03-30T02:11:49Z"}, {"author": "Martin Thomson", "text": "

@Lucas Pardue RS >> CRLF

", "time": "2023-03-30T02:11:59Z"}, {"author": "Martin Thomson", "text": "

Oh, I was partly or mostly being facetious

", "time": "2023-03-30T02:12:16Z"}, {"author": "Martin Duke", "text": "

Is the error code important to the use case, or is a FIN sufficient?

", "time": "2023-03-30T02:12:20Z"}, {"author": "Martin Thomson", "text": "

A FIN doesn't work for the first case

", "time": "2023-03-30T02:12:34Z"}, {"author": "Martin Duke", "text": "

I know that in RFC 9000 you can't send a FIN below the max seqno, but do we need the error code semantics?

", "time": "2023-03-30T02:13:08Z"}, {"author": "Matt Joras", "text": "

Martin: In discussions I've suggested that there be an error and non-error variant of doing something like this. The error is orthogonal to the mechanism here, which is signaling intention that only up to some offset will be reliably delivered

", "time": "2023-03-30T02:13:23Z"}, {"author": "Christian Huitema", "text": "

I have seen app developers getting very confused with reset, such as sending \"reset(some error code)\" only to see the reset dropped on the floor and never signalled because the FIN already arrived.

", "time": "2023-03-30T02:13:34Z"}, {"author": "Matt Joras", "text": "

What Marten is suggesting is not a \"real\" fin

", "time": "2023-03-30T02:13:39Z"}, {"author": "Martin Duke", "text": "

I guess what I'm saying is that another way to spell this is to allow a STREAM frame with FIN set and the offset below the max offset.

", "time": "2023-03-30T02:14:32Z"}, {"author": "Martin Thomson", "text": "

@Martin Duke you can't just send STREAM+FIN at the lower offset because that messes up flow control

", "time": "2023-03-30T02:14:36Z"}, {"author": "Matt Joras", "text": "

^^ that

", "time": "2023-03-30T02:14:44Z"}, {"author": "Martin Duke", "text": "

ah, yes

", "time": "2023-03-30T02:14:46Z"}, {"author": "Martin Thomson", "text": "

but yes, that is the way to conceptualize this

", "time": "2023-03-30T02:14:48Z"}, {"author": "Matt Joras", "text": "

so it's a sort of pseudo fin idea

", "time": "2023-03-30T02:15:05Z"}, {"author": "Matt Joras", "text": "

Hence why I don't think it should be associated with a \"reset\" or error terminology, it's not really about the error at all

", "time": "2023-03-30T02:15:29Z"}, {"author": "Ted Hardie", "text": "


", "time": "2023-03-30T02:15:43Z"}, {"author": "Martin Duke", "text": "

OOF (out of order FIN)

", "time": "2023-03-30T02:16:05Z"}, {"author": "Martin Thomson", "text": "


", "time": "2023-03-30T02:16:09Z"}, {"author": "Martin Thomson", "text": "

I'm not going to get in line, but we should adopt this

", "time": "2023-03-30T02:17:08Z"}, {"author": "Martin Thomson", "text": "

I prefer Marten's design

", "time": "2023-03-30T02:17:18Z"}, {"author": "Martin Thomson", "text": "

I don't like CLOSE_STREAM either

", "time": "2023-03-30T02:17:35Z"}, {"author": "Martin Duke", "text": "

Yes this seems more flexible than the payload option

", "time": "2023-03-30T02:17:43Z"}, {"author": "Matt Joras", "text": "

Hot take: I don't like the original reset terminology either

", "time": "2023-03-30T02:17:58Z"}, {"author": "Martin Thomson", "text": "

@Matt Joras you aren't the only one, but it eases the passage for TCP people

", "time": "2023-03-30T02:18:20Z"}, {"author": "Martin Thomson", "text": "

@Christian Huitema SHORT_FIN is not bad.

", "time": "2023-03-30T02:18:56Z"}, {"author": "Matt Joras", "text": "

sounds like a shark name

", "time": "2023-03-30T02:19:16Z"}, {"author": "Zaheduzzaman Sarker", "text": "

why is TCP people reading QUIC drafts ;-) ?

", "time": "2023-03-30T02:19:23Z"}, {"author": "Matt Joras", "text": "

Short-finned pilot whale is a real animal, nice image for future slides?

", "time": "2023-03-30T02:19:45Z"}, {"author": "Martin Thomson", "text": "

@Zaheduzzaman Sarker all people are capable of attaining redemption

", "time": "2023-03-30T02:19:54Z"}, {"author": "Mike Bishop", "text": "

To what Alan said (RESET without error code): I agree, don't do that.

", "time": "2023-03-30T02:21:01Z"}, {"author": "Matt Joras", "text": "

Don't call it a reset

", "time": "2023-03-30T02:21:10Z"}, {"author": "Matt Joras", "text": "

Just because HTTP loves error doesn't mean we should constrain all QUIC apps to such semantics ;)

", "time": "2023-03-30T02:21:25Z"}, {"author": "Martin Thomson", "text": "

Yeah, this isn't a reset, except to the extent to which it is

", "time": "2023-03-30T02:21:31Z"}, {"author": "Matt Joras", "text": "

we allow Streams to terminate without errors normally

", "time": "2023-03-30T02:21:39Z"}, {"author": "Matt Joras", "text": "

if we didn't we would have made fin an error code, and leave it to the app to make it the Application version of \"no error\"

", "time": "2023-03-30T02:21:58Z"}, {"author": "Andrew McGregor", "text": "

My comment about timestamps and timescales seems to mostly relate to rfc8877 and the history of the PTP alternate timescale field. I haven't right now found a naming scheme for epochs and timescales, but 8877 has some discussion.

", "time": "2023-03-30T02:22:38Z"}, {"author": "Martin Thomson", "text": "

@Martin Duke a separate extension, please

", "time": "2023-03-30T02:23:55Z"}, {"author": "Mike Bishop", "text": "

I think it should be a reset. If you look at the state machine, this is basically a RESET_STREAM that defers the transition to Reset Recevd until you've reached Data Recvd. (And potentially transitions from Size Known to Data Recvd at an earlier offset.)

", "time": "2023-03-30T02:24:04Z"}, {"author": "Mike Bishop", "text": "

I like RESET_STREAM_AT as a name.

", "time": "2023-03-30T02:24:17Z"}, {"author": "Martin Thomson", "text": "

I like \"ENOUGH\" for @Martin Duke's idea

", "time": "2023-03-30T02:24:30Z"}, {"author": "Alan Frindell", "text": "

My only question is: are we willing to support this as part of the QUIC API surface forever. Seems like folks like it

", "time": "2023-03-30T02:24:34Z"}, {"author": "Matt Joras", "text": "

Mike: my main contention with it being reset-ish is that reset enforces an error. An application could conceivably do this with no error to communicate, similar to how streams normally don't have to communicate an error on termination

", "time": "2023-03-30T02:27:05Z"}, {"author": "Robin Marx", "text": "

@Andrew: thank for the additional context

", "time": "2023-03-30T02:27:17Z"}, {"author": "Luke Curley", "text": "

just to clarify, the reliable reset isn't required for WebTransport, since the sender can already implement something like commit based on stream ACKs

", "time": "2023-03-30T02:27:24Z"}, {"author": "Matt Joras", "text": "

I think like Christian notes, this is a non-trivial problem for app developers. I've already heard feedback numerous times that reset having an error is annoying

", "time": "2023-03-30T02:27:37Z"}, {"author": "David Schinazi", "text": "

Can we reopen the queue for clarifying questions?

", "time": "2023-03-30T02:27:42Z"}, {"author": "Luke Curley", "text": "

but this new frame will reduce that reset by 1 RTT

", "time": "2023-03-30T02:27:43Z"}, {"author": "Alan Frindell", "text": "

Matt Joras said:


Mike: my main contention with it being reset-ish is that reset enforces an error. An application could conceivably do this with no error to communicate, similar to how streams normally don't have to communicate an error on termination


This is really dangerous in HTTP. We'd have to call it CACHE_POISON_AT

", "time": "2023-03-30T02:28:46Z"}, {"author": "Matt Joras", "text": "

Good thing we aren't the transport of HTTP :)

", "time": "2023-03-30T02:29:58Z"}, {"author": "Matt Joras", "text": "

it's definitely not something good for HTTP, but so will future QUIC features

", "time": "2023-03-30T02:30:08Z"}, {"author": "Alan Frindell", "text": "

RESET conveys an application defined code. If your app wants to define one that means NO_ERROR, that's ok.

", "time": "2023-03-30T02:30:14Z"}, {"author": "Matt Joras", "text": "

We don't require apps to communicate their NO_ERROR with stream fins, so we shouldn't with this thing either, IMO

", "time": "2023-03-30T02:30:41Z"}, {"author": "Alan Frindell", "text": "

I think it's just different than a FIN and want a way to distinguish

", "time": "2023-03-30T02:31:23Z"}, {"author": "Martin Thomson", "text": "

We should definitely avoid including the Identrust cross sign for the LE root in QUIC. All clients have LE in their trust store.

", "time": "2023-03-30T02:31:33Z"}, {"author": "Erik Nygren", "text": "

Some other TLS extensions in the pipeline might make this multi-RTT issue worse. For example, the ALPS extension for sending ACCEPT_CH will probably add some more for many websites, and I'm guessing ECH will add at least some more?

", "time": "2023-03-30T02:31:47Z"}, {"author": "Robin Marx", "text": "

@Erik: Is ALPS still a thing? I can't find updates to the original proposal since over a year ago?

", "time": "2023-03-30T02:33:16Z"}, {"author": "Luke Curley", "text": "

fun fact, the Twitch certificate is so large (thanks RSA) that it takes multiple round trips due to the amplification limit

", "time": "2023-03-30T02:34:22Z"}, {"author": "Luke Curley", "text": "

and for some reason they didn't support provisioning EDCSA certs to fix it...

", "time": "2023-03-30T02:34:50Z"}]