[{"author": "Lucas Pardue", "text": "

https://www.walesonline.co.uk/news/wales-news/celtic-roots-lie-spain-portugal-2174486

", "time": "2022-07-28T14:00:02Z"}, {"author": "Jonathan Lennox", "text": "

Lucas Pardue said:

\n
\n

\"boa tarde\" is awfully close to \"bore da\" - linked etymology?

\n
\n

Given that which word is \"good\" and which is \"day\" is reversed between the Romance and the Welsh, seems unlikely. :-)

", "time": "2022-07-28T14:00:36Z"}, {"author": "Ted Hardie", "text": "

Probably not; Portuguese usually only inherits Celtic words when they were first adopted into vulgar Latin. https://en.wikipedia.org/wiki/Portuguese_vocabulary#Celtic has some that survived/were adopted in.

", "time": "2022-07-28T14:01:34Z"}, {"author": "Lucas Pardue", "text": "

in Wales, every day is good

", "time": "2022-07-28T14:02:05Z"}, {"author": "Jonathan Morton", "text": "

ah, Welsh, the only language where \"good\" and \"raining\" resolve to the same word\u2026 (jk)

", "time": "2022-07-28T14:02:55Z"}, {"author": "Jonathan Hoyland", "text": "

I didn't know there was a MASQUE RFC to be compliant to

", "time": "2022-07-28T14:03:33Z"}, {"author": "Jonathan Morton", "text": "

I'll relay messages prefixed with \"Mic:\" or similar

", "time": "2022-07-28T14:04:40Z"}, {"author": "Eric Kinnear", "text": "

Bottom right below the send button: image.png

\n
", "time": "2022-07-28T14:06:07Z"}, {"author": "Lucas Pardue", "text": "

:clap:

", "time": "2022-07-28T14:06:46Z"}, {"author": "Martin Thomson", "text": "

YAR: Yet Another RFC

", "time": "2022-07-28T14:06:59Z"}, {"author": "Martin Thomson", "text": "

6 editors will attract questions

", "time": "2022-07-28T14:10:12Z"}, {"author": "Lucas Pardue", "text": "

3 editors, 3 authors

", "time": "2022-07-28T14:10:26Z"}, {"author": "Lucas Pardue", "text": "

we're aware MT, and have already been working with the responsible AD

", "time": "2022-07-28T14:10:55Z"}, {"author": "Martin Thomson", "text": "

kramdown-rfc has a \"contributors\" section, I believe

", "time": "2022-07-28T14:12:03Z"}, {"author": "Zaheduzzaman Sarker", "text": "

I would expect the Shepherd write up would add the explanation.

", "time": "2022-07-28T14:17:55Z"}, {"author": "Lucas Pardue", "text": "

+1 to Zahed. The current status was agreed between authors, chairs and ADs after careful consideration prior to formal adoption

", "time": "2022-07-28T14:21:14Z"}, {"author": "Lucas Pardue", "text": "

lets not spend time here chatting, we can take it offline if you have further comments MT

", "time": "2022-07-28T14:21:51Z"}, {"author": "Sean Turner", "text": "

can we get a mic reminder to mask up?

", "time": "2022-07-28T14:23:16Z"}, {"author": "Lucas Pardue", "text": "

ack

", "time": "2022-07-28T14:24:00Z"}, {"author": "Sean Turner", "text": "

addressed

", "time": "2022-07-28T14:25:12Z"}, {"author": "Lucas Pardue", "text": "

ack

", "time": "2022-07-28T14:25:20Z"}, {"author": "Matt Joras", "text": "

+1 Jana. This point (the offload doesn't control the packet numbering) has been something NIC vendors do not typically want to do, but it is possible to solve.

", "time": "2022-07-28T14:25:36Z"}, {"author": "Mike Bishop", "text": "

Actually, I think the mic reminder would be useful. I see several folks taking \"mask breaks.\"

", "time": "2022-07-28T14:26:55Z"}, {"author": "Jana Iyengar", "text": "

One more thing - multipath likely implies different NICs, and hardware offload likely also means that different NICs are handling parts of the connection anyway. This means no single NIC will have a view of the entire connection.

", "time": "2022-07-28T14:26:57Z"}, {"author": "Jonathan Morton", "text": "

sometimes, not always - different at each end of the connection, for example

", "time": "2022-07-28T14:27:56Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, presumably clients are more likely to be using multiple NICs, and servers are more likely to be using hardware offload.

", "time": "2022-07-28T14:29:46Z"}, {"author": "Christian Huitema", "text": "

Eric is confused. He is confusing the \"path challenge\" used to initiate a path, and the two path challenges sent by the receiver of an unextecpted packet, to check whether this is due to NAT traversal. But the two scenarios are different -- a challenge for a new path carries a new CID.

", "time": "2022-07-28T14:32:06Z"}, {"author": "Jana Iyengar", "text": "

Schinazi -- bring your MASQUE

", "time": "2022-07-28T14:32:59Z"}, {"author": "Kazuho Oku", "text": "", "time": "2022-07-28T14:33:16Z"}, {"author": "Nick Banks", "text": "

+1 to what Ian says. I'd rather require just multiple than have to support both.

", "time": "2022-07-28T14:33:55Z"}, {"author": "Hang Shi", "text": "

is zero length CID required when use QUIC P2P?

", "time": "2022-07-28T14:34:00Z"}, {"author": "Vidhi Goel", "text": "

Agree with supporting only a single option - multiple pns

", "time": "2022-07-28T14:35:50Z"}, {"author": "Erik Nygren", "text": "

(Meedecho). Are other folks having audio issues? I've been having significant drop-outs and garbling. I asked some other people who may also be having similar issues. In one case, exiting a browser and rejoining helped.

", "time": "2022-07-28T14:36:20Z"}, {"author": "Vidhi Goel", "text": "

I don\u2019t think single packet number space actually complicates the implementation

", "time": "2022-07-28T14:36:36Z"}, {"author": "Vidhi Goel", "text": "

I meant, I think single packet \u2026.

", "time": "2022-07-28T14:37:20Z"}, {"author": "Jonathan Morton", "text": "

@Erik: it works fine for me, maybe pause one or more inbound video streams to get clearer audio

", "time": "2022-07-28T14:37:22Z"}, {"author": "Jonathan Morton", "text": "

in this session we have 4-5 simultaneous video streams which is a bit of a BW hog

", "time": "2022-07-28T14:38:11Z"}, {"author": "Jonathan Lennox", "text": "

I'd be worried that single PN space could be an attractive nuisance for implementors to do a bad multipath implementation where they claim they support multipath but don't actually split out the congestion control across the connections. Which would be another argument for multiple PN spaces.

", "time": "2022-07-28T14:38:12Z"}, {"author": "Hang Shi", "text": "

@Jonathan This kind of multipath implementation will be unusable. Very easy to trigger the loss recovery.

", "time": "2022-07-28T14:40:08Z"}, {"author": "Hang Shi", "text": "

I have tried it and give up. Then I pick the multiple packet number space route

", "time": "2022-07-28T14:41:02Z"}, {"author": "Eric Kinnear", "text": "

Christian Huitema said:

\n
\n

Eric is confused.

\n
\n

Often!

\n
\n

He is confusing the \"path challenge\" used to initiate a path, and the two path challenges sent by the receiver of an unextecpted packet, to check whether this is due to NAT traversal. But the two scenarios are different -- a challenge for a new path carries a new CID.

\n
\n

In this case, RFC9000 states:

\n
In response to an apparent migration, endpoints MUST validate the\npreviously active path using a PATH_CHALLENGE frame.\n
\n

And separately:

\n
Not all changes of peer address are intentional, or active, migrations. The peer\ncould experience NAT rebinding: a change of address due to a middlebox, usually\na NAT, allocating a new outgoing port or even a new outgoing IP address for a flow.\nAn endpoint MUST perform path validation (Section 8.2) if it detects any change to\na peer's address, unless it has previously validated that address.\n
\n

We did leave some wiggle room for people to implement heuristics surrounding a repeated CID for a packet that arrives on a new path. But the NAT rebinding case is actually the case where you most need to validate the original and new path. So it appears that you would indeed send a challenge on both the old and the new path every time.
\nThat said, we could adjust this for multipath, but we still need the same defense against forwarders, which is painful in many ways.

", "time": "2022-07-28T14:42:04Z"}, {"author": "Jonathan Morton", "text": "

as I understand it:
\n1: client probes new path
\n2a: server challenges both paths OR
\n2b: server rejects new path via old path

", "time": "2022-07-28T14:44:14Z"}, {"author": "Eric Kinnear", "text": "

I think the original intent was

", "time": "2022-07-28T14:44:39Z"}, {"author": "Jonathan Morton", "text": "

I could be wrong since I haven't studied this closely

", "time": "2022-07-28T14:44:53Z"}, {"author": "Luke Curley", "text": "

apologies for my awkward time at the microphone, but I wanted to ask if there's other use-cases that would benefit from multiple packet space numbers

", "time": "2022-07-28T14:47:25Z"}, {"author": "Jana Iyengar", "text": "

There seems to be quite lound and violent agreement on doing multiple PN spaces. Chairs: Is this something we can call for consensus on? It'll put this issue to rest until new information emerges, and it will help the work move forward with clarity.

", "time": "2022-07-28T14:47:34Z"}, {"author": "Eric Kinnear", "text": "
    \n
  1. server sees packet arrive on new path from client (whether or not the client is intentionally probing a new path)
    \n2a. server challenges both paths OR
    \n2b. server challenges old path _and_ sends path abandon on old path to keep new path from coming up (which is potentially a problem for a client that's experienced an unintentional change and now the connection is dead, but that's a different issue to discuss)
    2. \n
\n

The question is mostly whether or not we want it to look like that -- having it be a new frame vs. a path challenge frame seems okay, should be fine for them to be in different packets/arrive in any order, etc.

", "time": "2022-07-28T14:47:34Z"}, {"author": "Luke Curley", "text": "

arbitrary packet spaces, independent of the path, actually seems quite useful as QUIC functionality

", "time": "2022-07-28T14:48:34Z"}, {"author": "Hang Shi", "text": "

Why would an application care about packet spaces?

", "time": "2022-07-28T14:49:57Z"}, {"author": "Jonathan Morton", "text": "

Jana: I can relay your comment if audio is a problem?

", "time": "2022-07-28T14:50:25Z"}, {"author": "Luke Curley", "text": "

@Hang Shi WebTransport and MASQUE multiplex \"sessions\" over a single QUIC connection to share encryption/routing, and need some way to tell each session apart

", "time": "2022-07-28T14:51:40Z"}, {"author": "Luke Curley", "text": "

very similar to how multi-path shares a QUIC connection and needs a way to tell each path apart

", "time": "2022-07-28T14:52:10Z"}, {"author": "Lucas Pardue", "text": "

my 2c: application sessions belong in the application

", "time": "2022-07-28T14:52:29Z"}, {"author": "Hang Shi", "text": "

WebTrans and MASQUE can do that in HTTP/3 stream

", "time": "2022-07-28T14:52:57Z"}, {"author": "Christian Huitema", "text": "

Eric, the difference is how the new path is created. In the \"intentional\" case, the client creates a packet with a new CID to send a challenge on the new path. The server can identify this case because both the path and the CID have not been seen before.

", "time": "2022-07-28T14:53:06Z"}, {"author": "Hang Shi", "text": "

Packet number space should be kept inside QUIC

", "time": "2022-07-28T14:53:27Z"}, {"author": "Christian Huitema", "text": "

In the NAT case, the client is just sending a regular packet, and the server is using Challenges to test whether this was spurious or not.

", "time": "2022-07-28T14:53:56Z"}, {"author": "Magnus Westerlund", "text": "

@Luke Curley I don't see how that can work as a single application session can be sent over multiple paths to achieve desired transport properties. So they are different levels and do need to be handled separately. Are I misunderstanding what you attempt to say?

", "time": "2022-07-28T14:54:00Z"}, {"author": "Erik Nygren", "text": "

Has anyone tried in implementations to see how multiple spaces (vs a single one) would make it easier to have different processes/cores/etc handling different streams on a single connection with less lock contention?

", "time": "2022-07-28T14:54:06Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Luke Curley I don't think webtrans and masque's use of contexts is the same as multipath quic's, and think they should be separate.

", "time": "2022-07-28T14:54:14Z"}, {"author": "Luke Curley", "text": "

@Alex Chernyakhovsky agreed; each application treats the context differently

", "time": "2022-07-28T14:54:54Z"}, {"author": "Gorry Fairhurst", "text": "

It seems to me that there are many things a transport has to (and more in future) track about path characteristics, and each path could be quite different or have different patterns of disruption, and this might be a logical reason why we use multiple sequence spaces.

", "time": "2022-07-28T14:54:57Z"}, {"author": "Luke Curley", "text": "

it just seems strange that each draft is forking QUIC frames to add a \"context\" at the start, like MP_ACK

", "time": "2022-07-28T14:55:24Z"}, {"author": "Erik Nygren", "text": "

Jana had a good question on if there should be a show-of-hands on whether continuing with zero-length/single-space or just doing multiple-space makes sense?

", "time": "2022-07-28T14:55:24Z"}, {"author": "Brian Trammell", "text": "

i think the sense was decide later after a bit more impl experience

", "time": "2022-07-28T14:55:50Z"}, {"author": "Brian Trammell", "text": "

perhaps a hackathon table

", "time": "2022-07-28T14:55:56Z"}, {"author": "Jonathan Morton", "text": "

my sense as a semi-outsider is that multiple PNs would be appropriate for multipath, single PN is adequate for non-multipath

", "time": "2022-07-28T14:56:00Z"}, {"author": "Alex Chernyakhovsky", "text": "

What is \"each draft\" here? I don't think any masque or webtrans drafts are forking any quic frames

", "time": "2022-07-28T14:56:26Z"}, {"author": "Jake Holland", "text": "

Capsules are sort of doing that.

", "time": "2022-07-28T14:57:03Z"}, {"author": "Jana Iyengar", "text": "

@Erik -- Lucas said that there might be something on email.

", "time": "2022-07-28T14:57:18Z"}, {"author": "Luke Curley", "text": "

@Alex Chernyakhovsky check my email to the webtrans ML

", "time": "2022-07-28T14:57:28Z"}, {"author": "Luke Curley", "text": "

right now it seems like we've got capsules for RESET_STREAM and the MAX_* frames to add a context in the front

", "time": "2022-07-28T14:58:36Z"}, {"author": "Jonathan Hoyland", "text": "

Wait, @David Schinazi, are you not a QUIC enthusiast?

", "time": "2022-07-28T14:58:52Z"}, {"author": "Luke Curley", "text": "

each STREAM starts with a context frame, and DATAGRAM has context built-in

", "time": "2022-07-28T14:59:23Z"}, {"author": "Christian Huitema", "text": "

+1 Martin. There is a huge difference between 0 byte and 1 byte, but not so much between 1 and 2.

", "time": "2022-07-28T15:00:00Z"}, {"author": "David Schinazi", "text": "

What a beautiful bikeshed we have

", "time": "2022-07-28T15:00:15Z"}, {"author": "Jonathan Morton", "text": "

+1 Chris

", "time": "2022-07-28T15:00:19Z"}, {"author": "Kazuho Oku", "text": "

+1 to MT. Intent of ack-frequency is to reduce ACKs, we should not be inducing that much of ACKs.

", "time": "2022-07-28T15:00:21Z"}, {"author": "Mirja K\u00fchlewind", "text": "

yellow

", "time": "2022-07-28T15:01:02Z"}, {"author": "Jonathan Morton", "text": "

I agree that IMMEDIATE_ACK wouldn't be sent often - if you need to send a huge number, just preset a high frequency using ACK_FREQ

", "time": "2022-07-28T15:01:25Z"}, {"author": "Spencer Dawkins", "text": "

+1 on Martin, and why change this now?

", "time": "2022-07-28T15:02:10Z"}, {"author": "Martin Thomson", "text": "

The three mart[ie]ns all made it to the mic on this topic. So confusing.

", "time": "2022-07-28T15:02:47Z"}, {"author": "Gorry Fairhurst", "text": "

Once/Twice per RTT with many 100s of packets in flights is a small overhead anyway...

", "time": "2022-07-28T15:03:22Z"}, {"author": "Matt Joras", "text": "

yeah, even if you are doing things like tacking this on to every time the sender becomes app-limited or runs out of CWND, i.e. at the tail of a send, it's really not a big deal to have an extra byte

", "time": "2022-07-28T15:04:00Z"}, {"author": "Eric Kinnear", "text": "

Christian Huitema said:

\n
\n

In the NAT case, the client is just sending a regular packet, and the server is using Challenges to test whether this was spurious or not.

\n
\n

Agreed that there are heuristics you can use to detect a likely NAT rebinding (this being an obvious one, some others are listed at the end of that section), but my understanding is that the server must challenge regardless.

", "time": "2022-07-28T15:04:01Z"}, {"author": "Matt Joras", "text": "

people vastly overestimate the measurable difference a couple bytes overhead makes. Even changing packet size e.g. from 1232 -> 1252 is not really measurable in any meaningful way

", "time": "2022-07-28T15:04:33Z"}, {"author": "Jonathan Morton", "text": "

there's four Jonathans in the room too, and all spelled the same way which is unusual

", "time": "2022-07-28T15:04:40Z"}, {"author": "Jonathan Hoyland", "text": "

You mean correctly?

", "time": "2022-07-28T15:05:20Z"}, {"author": "Martin Thomson", "text": "

cut it!

", "time": "2022-07-28T15:05:33Z"}, {"author": "Jonathan Morton", "text": "

there were apparently two alternative spellings more common than mine where I grew up

", "time": "2022-07-28T15:05:56Z"}, {"author": "Spencer Dawkins", "text": "

+1 Matt. This gives you a mechanism and a way to evolve advice about strategies.

", "time": "2022-07-28T15:11:43Z"}, {"author": "Jake Holland", "text": "

+1 to matt. The less said here the better, probably.

", "time": "2022-07-28T15:11:45Z"}, {"author": "Christian Huitema", "text": "

+1 Matt. Define the AF formats in the draft, leave strategies to others.

", "time": "2022-07-28T15:12:20Z"}, {"author": "Robin Marx", "text": "

Gorry is difficult to understand for the note takers

", "time": "2022-07-28T15:12:21Z"}, {"author": "Spencer Dawkins", "text": "

Robin Marx said:

\n
\n

Gorry is difficult to understand for the note takers

\n
\n

The longer he talks, the easier he is to understand. Ask him to mumble for 30 seconds before he makes his point? :grinning_face_with_smiling_eyes:

", "time": "2022-07-28T15:13:44Z"}, {"author": "Jake Holland", "text": "

In the original agenda he has negative 3 minutes...

", "time": "2022-07-28T15:13:57Z"}, {"author": "Jake Holland", "text": "

;)

", "time": "2022-07-28T15:14:10Z"}, {"author": "Lucas Pardue", "text": "

chair discretion

", "time": "2022-07-28T15:14:20Z"}, {"author": "Christian Huitema", "text": "

The more I listen to Ian, the more I believe Matt's comment that less is more.

", "time": "2022-07-28T15:15:07Z"}, {"author": "Gorry Fairhurst", "text": "

@Robin sorry ...

", "time": "2022-07-28T15:15:09Z"}, {"author": "Jake Holland", "text": "

Yeah yeah. Wouldn't want to get the byte count wrong, I understand.

", "time": "2022-07-28T15:15:22Z"}, {"author": "Jana Iyengar", "text": "

audio issues, apologies. Apparently something seem to like my mic

", "time": "2022-07-28T15:17:27Z"}, {"author": "Gorry Fairhurst", "text": "

+1 I like the reordering threshold much more than ignore order

", "time": "2022-07-28T15:17:49Z"}, {"author": "Jonathan Morton", "text": "

again, I can relay if need be

", "time": "2022-07-28T15:17:54Z"}, {"author": "Jana Iyengar", "text": "

I'll type: If anyone thinks differently, please say something now about retaining ignore order, else reordering threshold is likely the direction we'll go.

", "time": "2022-07-28T15:18:15Z"}, {"author": "Eric Kinnear", "text": "

At first glance, reordering threshold seems like a good answer

", "time": "2022-07-28T15:18:39Z"}, {"author": "Jana Iyengar", "text": "

Now's the time to take a second glance, Erik :-)

", "time": "2022-07-28T15:19:43Z"}, {"author": "Jana Iyengar", "text": "

(sorry, EriC)

", "time": "2022-07-28T15:19:58Z"}, {"author": "Jonathan Hoyland", "text": "

Top left of MeetEcho

", "time": "2022-07-28T15:25:17Z"}, {"author": "Christine Pukropski", "text": "

@Martin Duke I work at Linode (a cloud computing provider now Akamai) and have worked on our loadbalancer product extensively. I need to review the RFC in detail but would love to chat more.

", "time": "2022-07-28T15:25:26Z"}, {"author": "David Schinazi", "text": "
", "time": "2022-07-28T15:25:33Z"}, {"author": "Jonathan Hoyland", "text": "

:rolling_on_the_floor_laughing:

", "time": "2022-07-28T15:25:49Z"}, {"author": "Spencer Dawkins", "text": "

I like many things about Meetecho, but for things I don't do often (like, present slides from the datatracker), I find the idea of a former IAB chair needing help from a current IAB chair to pick the right button is somewhat precious ...

", "time": "2022-07-28T15:26:36Z"}, {"author": "Jana Iyengar", "text": "
", "time": "2022-07-28T15:27:03Z"}, {"author": "Jonathan Morton", "text": "

a text label under the icon might help

", "time": "2022-07-28T15:27:53Z"}, {"author": "Jana Iyengar", "text": "

\"https://i.imgflip.com/2srug2.jpg\"

\n
", "time": "2022-07-28T15:28:06Z"}, {"author": "Jonathan Morton", "text": "

currently there is a tooltip but that's hard to discover quickly

", "time": "2022-07-28T15:28:19Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I'm from the IAB and here to help

", "time": "2022-07-28T15:28:28Z"}, {"author": "Mirja K\u00fchlewind", "text": "

But I guess the other button is actually called \"join queue\" and not \"raise hand\"...

", "time": "2022-07-28T15:29:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

but you know what I mean

", "time": "2022-07-28T15:29:22Z"}, {"author": "Robin Marx", "text": "

(from experience, I can tell you that PhDs just look at your articles though Christian ;))

", "time": "2022-07-28T15:30:03Z"}, {"author": "Hang Shi", "text": "

Does this imply time sync between both ends?

", "time": "2022-07-28T15:30:49Z"}, {"author": "Jonathan Lennox", "text": "

I think it implies they don't have significant drift between them, but not absolute sync.

", "time": "2022-07-28T15:32:07Z"}, {"author": "Spencer Dawkins", "text": "

Jonathan Lennox said:

\n
\n

I think it implies they don't have significant drift between them, but not absolute sync.

\n
\n

That's my understanding as well, but Christian can tell us when he finishes presenting ...

", "time": "2022-07-28T15:34:01Z"}, {"author": "Jonathan Hoyland", "text": "

I mean, you have to assume Einstein synchronisation

", "time": "2022-07-28T15:34:22Z"}, {"author": "Jonathan Hoyland", "text": "

Because we can't measure the one-way speed of light.

", "time": "2022-07-28T15:35:07Z"}, {"author": "Varun Singh", "text": "

If the receiver echos the timestamp, you get RTT

", "time": "2022-07-28T15:36:38Z"}, {"author": "Spencer Dawkins", "text": "

Timestamps have also gotten interest in the discussions about realtime/interactive media over QUIC.

", "time": "2022-07-28T15:36:50Z"}, {"author": "Jana Iyengar", "text": "

Gah. I can't win with meetecho.

", "time": "2022-07-28T15:37:38Z"}, {"author": "Varun Singh", "text": "

or if both parties add timestamp, maybe the sender can calculate skew... but that would require successive packets or something like that

", "time": "2022-07-28T15:37:45Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, most of the RMCAT-style CC algorithms (notably GCC which is the congestion controller in libwebrtc) use timestamps for one-way delay.

", "time": "2022-07-28T15:37:52Z"}, {"author": "Gorry Fairhurst", "text": "

@Jana, Making the Internet work well is hard :-)

", "time": "2022-07-28T15:38:24Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@jana we can relay for you if you want

", "time": "2022-07-28T15:39:07Z"}, {"author": "ShangLing Deng", "text": "

If timestamps are added at both ends, packets with excessive delay may be discarded based on the timestamps.

", "time": "2022-07-28T15:39:46Z"}, {"author": "Gorry Fairhurst", "text": "

+1 on Timestamps seeming potentially quite useful for various things!

", "time": "2022-07-28T15:39:46Z"}, {"author": "Nick Banks", "text": "

+1 as well

", "time": "2022-07-28T15:40:16Z"}, {"author": "Varun Singh", "text": "

I can work with Christian, if there is a need for more people to think through this

", "time": "2022-07-28T15:40:17Z"}, {"author": "Zaheduzzaman Sarker", "text": "", "time": "2022-07-28T15:40:54Z"}, {"author": "Jana Iyengar", "text": "

So, first, I think this ought to be not OWD, but OWD-delta, since that is what the algorithm is capable of measuring. Second, there's a question of use -- and as it stands, only the receiver can use it. The value of ts in TCP is that it can be used to unambiguously tell RTT changes, where with QUIC we dont have that problem to begin with, because of unique PNs.

\n

That said, this can be an experimental draft that people can play with and see if it needs to be standardized. I don't see the value of adopting and standardizing something that doesn't have people wanting to implement and experiment with, else we end up in theoretical design land through getting this to RFC.

", "time": "2022-07-28T15:42:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

The charter says: \"The WG will primarily focus on extensions to the QUIC transport layer, i.e., extensions to QUIC that have broad applicability to multiple application protocols. The WG may also publish specifications to publicly document deployed proprietary extensions or to enable wider experimentation with proposed new protocol features.\"

", "time": "2022-07-28T15:42:25Z"}, {"author": "Matt Joras", "text": "

fwiw: we have a usecase where we want a way of doing this, but it's with the \"yet another ACK frame\" mechanism

", "time": "2022-07-28T15:42:52Z"}, {"author": "Jana Iyengar", "text": "

Specifically, I think there's value in having the draft, but I don't think we need to have adoption unless people want to use this work.

", "time": "2022-07-28T15:43:03Z"}, {"author": "Ted Hardie", "text": "

I'm surprised by this characterization of the MoQ BoF as not as much of a train as it might have been. I think it went pretty well, and I encourage anyone who wasn't there to review the recording when its available.

", "time": "2022-07-28T15:44:54Z"}, {"author": "Gorry Fairhurst", "text": "

I wondered: would the WG making an EXP spec start this process, and allow people to have wider experimentation with proposed new protocol features?

", "time": "2022-07-28T15:45:12Z"}, {"author": "Jake Holland", "text": "

That seems a decent idea.

", "time": "2022-07-28T15:45:40Z"}, {"author": "Luke Curley", "text": "

I kind of zoned out, but would this TIMESTAMP proposal enable measuring per-packet arrival times?

", "time": "2022-07-28T15:46:12Z"}, {"author": "Jake Holland", "text": "

Echoing timestamps also seems useful here for some of the use cases.

", "time": "2022-07-28T15:46:20Z"}, {"author": "Luke Curley", "text": "

or is it still limited due to ack batching?

", "time": "2022-07-28T15:46:21Z"}, {"author": "Spencer Dawkins", "text": "

Ted Hardie said:

\n
\n

I'm surprised by this characterization of the MoQ BoF as not as much of a train as it might have been. I think it went pretty well, and I encourage anyone who wasn't there to review the recording when its available.

\n
\n

Ted, my apologies. My intention was to say that it went pretty well, better than I thought it might (and thanks to you and Alan for your work making that happen).

", "time": "2022-07-28T15:46:23Z"}, {"author": "Jake Holland", "text": "

Seems relevant for most work tho, yes.

", "time": "2022-07-28T15:47:34Z"}, {"author": "Jake Holland", "text": "

Moq

", "time": "2022-07-28T15:47:44Z"}, {"author": "Jana Iyengar", "text": "

@jake -- as it turns out, you don't need echoes.

", "time": "2022-07-28T15:47:53Z"}, {"author": "Jana Iyengar", "text": "

you get that info from the packet numbers and acks (and ack delay info in the acks). This is why QUIC doesn't explicitly need timestamps to get to mechanisms that TCP needs timestamps for.

", "time": "2022-07-28T15:48:39Z"}, {"author": "David Schinazi", "text": "

Oh Multicast Enthusiast, that's a new one

", "time": "2022-07-28T15:48:47Z"}, {"author": "Jana Iyengar", "text": "

Multicast!

", "time": "2022-07-28T15:49:05Z"}, {"author": "Brian Trammell", "text": "

many new ones, all at the same time, with variable delay

", "time": "2022-07-28T15:49:12Z"}, {"author": "Spencer Dawkins", "text": "

Ted Hardie said:

\n
\n

I'm surprised by this characterization of the MoQ BoF as not as much of a train as it might have been. I think it went pretty well, and I encourage anyone who wasn't there to review the recording when its available.

\n
\n

And, after apologizing to Ted, I note that the recording IS available now, at https://play.conf.meetecho.com/Playout/?session=IETF114-MOQ-20220727-1400, and I also encourage people to review that, as time permits.

", "time": "2022-07-28T15:49:44Z"}, {"author": "Kyle Rose", "text": "

Why is there no camera on the speaker? Weird.

", "time": "2022-07-28T15:50:50Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho, can we adjust the camera please?

", "time": "2022-07-28T15:51:04Z"}, {"author": "Lucas Pardue", "text": "

@meetecho coudl we point the camera to the presenter in the room please

", "time": "2022-07-28T15:51:05Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@meetecho can you adjust the camera?

", "time": "2022-07-28T15:51:07Z"}, {"author": "Mirja K\u00fchlewind", "text": "

okay that should do it ;-)

", "time": "2022-07-28T15:51:26Z"}, {"author": "Jonathan Hoyland", "text": "

Thanks!

", "time": "2022-07-28T15:51:28Z"}, {"author": "Kyle Rose", "text": "

Thanks to whoever fixed that

", "time": "2022-07-28T15:51:37Z"}, {"author": "Ted Hardie", "text": "

Thanks for the pointer, Spencer

", "time": "2022-07-28T15:51:38Z"}, {"author": "Zaheduzzaman Sarker", "text": "

all the video feeds are frozen on my computer :-(

", "time": "2022-07-28T15:52:52Z"}, {"author": "Jonathan Morton", "text": "

pause some of them, should help

", "time": "2022-07-28T15:53:42Z"}, {"author": "Zaheduzzaman Sarker", "text": "

but meetecho thinks I am doing a great job by just sitting here.. may be thats why ;-)

", "time": "2022-07-28T15:54:19Z"}, {"author": "Jonathan Morton", "text": "

I like the Github username

", "time": "2022-07-28T15:55:28Z"}, {"author": "Lars Eggert", "text": "

i am disappointed there is no MC_HAMMER

", "time": "2022-07-28T15:56:02Z"}, {"author": "David Schinazi", "text": "

nice

", "time": "2022-07-28T15:56:24Z"}, {"author": "Jonathan Morton", "text": "

would you use that top stop the stream?

", "time": "2022-07-28T15:56:30Z"}, {"author": "Lucas Pardue", "text": "

this design is quite different from draft-pardue-quic-multicast

", "time": "2022-07-28T15:59:42Z"}, {"author": "David Schinazi", "text": "

I'm sad Lars didn't do the MC_HAMMER dance at the mic

", "time": "2022-07-28T16:00:40Z"}, {"author": "Spencer Dawkins", "text": "

Zaheduzzaman Sarker said:

\n
\n

but meetecho thinks I am doing a great job by just sitting here.. may be thats why ;-)

\n
\n

It knows you're an AD. But seriously, it's working for me. Is there anything you need someone with working video to tell you?

", "time": "2022-07-28T16:01:35Z"}, {"author": "Robin Marx", "text": "

As it looks like there won't be time for the final item on Protocol Analyzers: i'm obviously very interested in this. Please keep me in the loop in future efforts, thanks :) @Emile

", "time": "2022-07-28T16:02:04Z"}, {"author": "Luke Curley", "text": "

yeah to elaborate, there's a few MoQ proposals that push identical media over server-initiated unidirectional streams, so in theory you could use multi-cast transparently

", "time": "2022-07-28T16:02:21Z"}, {"author": "Kyle Rose", "text": "

The multicast use case is yet another argument in favor of multiple packet number spaces.

", "time": "2022-07-28T16:02:43Z"}, {"author": "Chris Box", "text": "

QUIC multicast has huge potential. Definitely support this becoming a reality. BT has multicast capability to millions of UK homes so I'd like to leverage that.

", "time": "2022-07-28T16:02:44Z"}, {"author": "Zaheduzzaman Sarker", "text": "

no, stop - start seems like woking

\n

Spencer Dawkins said:

\n
\n

Zaheduzzaman Sarker said:

\n
\n

but meetecho thinks I am doing a great job by just sitting here.. may be thats why ;-)

\n
\n

It knows you're an AD. But seriously, it's working for me. Is there anything you need someone with working video to tell you?

\n
\n

thanks, stop -start seems working

", "time": "2022-07-28T16:02:56Z"}, {"author": "Spencer Dawkins", "text": "

Kyle Rose said:

\n
\n

The multicast use case is yet another argument in favor of multiple packet number spaces.

\n
\n

Yes, very much.

", "time": "2022-07-28T16:03:18Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho Adjourned

", "time": "2022-07-28T16:03:59Z"}, {"author": "Brian Trammell", "text": "

\\o enjoy lunch y'all

", "time": "2022-07-28T16:04:02Z"}, {"author": "Jana Iyengar", "text": "

too early for lunch

", "time": "2022-07-28T16:04:13Z"}]