[{"author": "Watson Ladd", "text": "

david is slightly off the mic1 camera view

", "time": "2024-07-23T22:35:36Z"}, {"author": "Watson Ladd", "text": "

I can!

", "time": "2024-07-23T22:36:25Z"}, {"author": "Watson Ladd", "text": "

help welcome

", "time": "2024-07-23T22:37:36Z"}, {"author": "Christian Huitema", "text": "

Love the transscript: Mayor Kuleiman ... actually agree with men!

", "time": "2024-07-23T22:46:54Z"}, {"author": "Magnus Westerlund", "text": "

I would note that QUIC is not the only UDP using protocol that has migration. When one uses ICE one have some interesting migration scenarios that actually requires one to send to multiple targets from the same proxy external IP:Port. But, this is getting solved with UDP listen. So in fact UDP listen can actually support the migration case also.

", "time": "2024-07-23T22:51:15Z"}, {"author": "Kevin Cox", "text": "

I think it is important to communicate to the client that retrying won't help to avoid a useless retry loop.

", "time": "2024-07-23T22:51:27Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Magnus Westerlund Definitely, but I don't think that means we shouldn't provide QUIC-specific guidance in the QUIC-aware proxying document?

", "time": "2024-07-23T22:53:13Z"}, {"author": "Magnus Westerlund", "text": "

No, for the QUIC migration, using a new connect-UDP request is so much simpler. But if one have a proxy that support one could use it, just a realisation.

", "time": "2024-07-23T22:54:03Z"}, {"author": "Magnus Westerlund", "text": "

And I am fine with guidance in QUIC-Aware doc.

", "time": "2024-07-23T22:54:28Z"}, {"author": "Martin Thomson", "text": "

Longer than the connection?

", "time": "2024-07-23T22:55:23Z"}, {"author": "Martin Thomson", "text": "

So 2^62-1 bytes?

", "time": "2024-07-23T22:55:32Z"}, {"author": "Mike Bishop", "text": "

Connection ID; Tommy noted the missing \"ID\" already.

", "time": "2024-07-23T22:55:44Z"}, {"author": "Martin Thomson", "text": "

Shows how much I'm paying attention.

", "time": "2024-07-23T22:56:10Z"}, {"author": "Watson Ladd", "text": "

chairs table is quiet on the audio

", "time": "2024-07-23T22:56:19Z"}, {"author": "Dennis Jackson", "text": "

ah thanks, will project a little more

", "time": "2024-07-23T22:56:32Z"}, {"author": "Martin Thomson", "text": "

quiet, or silent?

", "time": "2024-07-23T22:56:42Z"}, {"author": "Watson Ladd", "text": "

quiet

", "time": "2024-07-23T22:56:47Z"}, {"author": "Martin Thomson", "text": "

OK, was concerned that you weren't hearing at all

", "time": "2024-07-23T22:57:00Z"}, {"author": "Magnus Westerlund", "text": "

Martin: Actually the connection can actually be longer than 2^62-1 bytes, can't it? The limit is 2^62-1 packets containing multiple streams where each stream can be maximum of 2^62-1 bytes?

", "time": "2024-07-23T22:57:26Z"}, {"author": "Martin Thomson", "text": "

Oh, Magnus out-pedants me!

", "time": "2024-07-23T22:57:47Z"}, {"author": "Martin Thomson", "text": "

I'm defeated

", "time": "2024-07-23T22:58:02Z"}, {"author": "Juliusz Chroboczek", "text": "

That's way more than Avogadro's number.

", "time": "2024-07-23T22:59:00Z"}, {"author": "Martin Thomson", "text": "

6.22e23?

", "time": "2024-07-23T22:59:20Z"}, {"author": "Juliusz Chroboczek", "text": "

Yes, 2^78.

", "time": "2024-07-23T22:59:31Z"}, {"author": "Martin Thomson", "text": "

Yeah, QUIC connections probably won't be that long.

", "time": "2024-07-23T23:00:01Z"}, {"author": "Martin Thomson", "text": "

But I don't know what you are measuring, and in what units.

", "time": "2024-07-23T23:00:18Z"}, {"author": "Martin Thomson", "text": "

Measuring bits of packets, you have to consider lost and retransmitted packets.

", "time": "2024-07-23T23:00:32Z"}, {"author": "Magnus Westerlund", "text": "

I think I am wrong, as the connection data flow control is the limit. But total number of data is still more as that is only content of DATA frames that are 2^62-1.

", "time": "2024-07-23T23:00:50Z"}, {"author": "Martin Thomson", "text": "

The only limit is packet numbers. Because you don't need to send STREAM frames. DATAGRAM has no inherent limits.

", "time": "2024-07-23T23:01:31Z"}, {"author": "Juliusz Chroboczek", "text": "

We count on you to settle this matter once and for all ;-)

", "time": "2024-07-23T23:01:34Z"}, {"author": "Mike Bishop", "text": "

Meetecho, mic1 camera is blurry again.

", "time": "2024-07-23T23:01:44Z"}, {"author": "Martin Thomson", "text": "

Oh yeah, while you are there Magnus, can you sort out b= in SDP? kthxbye

", "time": "2024-07-23T23:01:54Z"}, {"author": "Mike Bishop", "text": "

Thanks!

", "time": "2024-07-23T23:02:02Z"}, {"author": "Mike Bishop", "text": "

\"Public\" may be a misnomer here. They're addresses on the proxy assigned to the client; they need not be globally reachable for all scenarios.

", "time": "2024-07-23T23:03:50Z"}, {"author": "Jonathan Lennox", "text": "

\"External\"?

", "time": "2024-07-23T23:04:02Z"}, {"author": "Magnus Westerlund", "text": "

Martin Thomson said:

\n
\n

Oh yeah, while you are there Magnus, can you sort out b= in SDP? kthxbye

\n
\n

Tried with b=TIAS to make something slightly more sane. But, I would claim that for many usage the model is broken.

", "time": "2024-07-23T23:04:06Z"}, {"author": "Magnus Westerlund", "text": "

SDP i broken!

", "time": "2024-07-23T23:04:31Z"}, {"author": "Zaheduzzaman Sarker", "text": "

you mean SDP offer answer model is broken.....?

", "time": "2024-07-23T23:08:04Z"}, {"author": "Magnus Westerlund", "text": "

Especially, but even in declarative usages there are aspects like bandwidth that are broken or at least very limited.

", "time": "2024-07-23T23:09:53Z"}, {"author": "Juliusz Chroboczek", "text": "

Isn't bandwidth information carried by RTCP instead of SDP?

", "time": "2024-07-23T23:11:08Z"}, {"author": "Juliusz Chroboczek", "text": "

Is b= actually used in the wild?

", "time": "2024-07-23T23:11:24Z"}, {"author": "Magnus Westerlund", "text": "

So you need b=RS/RR: to configure RTCP bandwidth as there are no dynamic scaling for RTCP defined.

", "time": "2024-07-23T23:12:11Z"}, {"author": "Juliusz Chroboczek", "text": "

Interesting. Do you have an RFC number?

", "time": "2024-07-23T23:19:07Z"}, {"author": "Magnus Westerlund", "text": "

Many!

", "time": "2024-07-23T23:19:34Z"}, {"author": "Juliusz Chroboczek", "text": "

Right, I wasn't accurate enough. Could you please provide me with a reference to a document that explains how b= is used to scale RTCP?

", "time": "2024-07-23T23:20:45Z"}, {"author": "Magnus Westerlund", "text": "

Juliusz Chroboczek said:

\n
\n

Right, I wasn't accurate enough. Could you please provide me with a reference to a document that explains how b= is used to scale RTCP?

\n
\n

https://datatracker.ietf.org/doc/rfc3605/ is probably a good start

", "time": "2024-07-23T23:22:23Z"}, {"author": "Magnus Westerlund", "text": "

Sorry wrong doc

", "time": "2024-07-23T23:23:13Z"}, {"author": "Magnus Westerlund", "text": "

It is https://datatracker.ietf.org/doc/rfc3556/ that is relevant.

", "time": "2024-07-23T23:24:34Z"}, {"author": "Juliusz Chroboczek", "text": "

Thanks, noted.

", "time": "2024-07-23T23:26:28Z"}, {"author": "Magnus Westerlund", "text": "

You will note that this RFC is included in what you can do with JSEP for WebRTC. And as the RFC explains RR/RS is an alternative to assign a pre-defined percentage of AS/TIAS to RTCP.

", "time": "2024-07-23T23:26:42Z"}, {"author": "Juliusz Chroboczek", "text": "

Poor David.

", "time": "2024-07-23T23:31:40Z"}, {"author": "A.J. Stein", "text": "

I thought we were talking about _reprovisioning_ DNS (probably for privacy reasons, security, perhaps others) after bootstrapping the network connection.

", "time": "2024-07-23T23:35:10Z"}, {"author": "Juliusz Chroboczek", "text": "

Yes, they might be speaking at cross-purposes.

", "time": "2024-07-23T23:35:45Z"}, {"author": "A.J. Stein", "text": "

In my personal life, I am heavily reliant on using DNS, as a consumer, with a VPN service, separate from my ISP's control. David's proposal may seem less effective for corporate environments, but for individuals I would like the general mechanism he proposes with a MASQUE proxy. Am I missing something?

", "time": "2024-07-23T23:36:19Z"}, {"author": "Juliusz Chroboczek", "text": "

Agreed, but not only. David's mechanism is also useful for the connect to orporate networ usecase, which is a very common use of VPNs.

", "time": "2024-07-23T23:37:40Z"}, {"author": "Watson Ladd", "text": "

i think you agree with Tommy

", "time": "2024-07-23T23:37:45Z"}, {"author": "A.J. Stein", "text": "

Watson Ladd said:

\n
\n

i think you agree with Tommy

\n
\n

I guess I have to review the draft then. :smile:

", "time": "2024-07-23T23:38:43Z"}, {"author": "Watson Ladd", "text": "

someone poke Alex to check that i got the combinations that are good right

", "time": "2024-07-23T23:52:35Z"}]