[{"author": "Ingemar Johansson", "text": "

Hear you fine

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

all good then ;)

", "time": "2023-03-28T00:30:58Z"}, {"author": "Bob Briscoe", "text": "

Thanks David. Yes.Mea culpa!

", "time": "2023-03-28T00:37:35Z"}, {"author": "David Black", "text": "

@Bob - no problem - you've been very busy getting the L4S RFCs done!:slightly_smiling_face:

", "time": "2023-03-28T00:38:26Z"}, {"author": "Bob Briscoe", "text": "

Well, that was Jan. accurate-ecn more recently

", "time": "2023-03-28T00:42:27Z"}, {"author": "David Black", "text": "

I'm very familiar with that sort of \"can't be cloned\" problem ...

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

1mps can very well congest my own local link...

", "time": "2023-03-28T00:56:15Z"}, {"author": "Christian Huitema", "text": "

I would personally go for 64kbps or maybe 256kbps.

", "time": "2023-03-28T00:57:00Z"}, {"author": "Chris Box", "text": "

100Mbps definitely feels too high. Many many last miles are slower.

", "time": "2023-03-28T00:57:21Z"}, {"author": "Reese Enghardt", "text": "

I guess \"typical\" is very hard to pin down. Networks are very diverse

", "time": "2023-03-28T00:57:38Z"}, {"author": "Jason Livingood", "text": "

I like the idea of a % rather than a fixed number

", "time": "2023-03-28T00:57:39Z"}, {"author": "Ingemar Johansson", "text": "

What is the time perspective ?, yes, we have the situation today, but what about when NQB is rolled out

", "time": "2023-03-28T00:58:32Z"}, {"author": "Ingemar Johansson", "text": "

Is it 2 years?, 5 years?

", "time": "2023-03-28T00:59:05Z"}, {"author": "Chris Box", "text": "

+1 to what Jason said

", "time": "2023-03-28T01:02:55Z"}, {"author": "Bob Briscoe", "text": "

With caveats, this was a study I did in 2021 from openly available data - see Fig 6 or the data table on the page before: https://arxiv.org/pdf/2107.01003.pdf

", "time": "2023-03-28T01:02:58Z"}, {"author": "Christian Huitema", "text": "

something like 1% of min(local bandwdwidth, some internet average)?

", "time": "2023-03-28T01:03:09Z"}, {"author": "Erik Nygren", "text": "

Would associating it with a function of initial congestion windows make sense? (Since those have similar properties for how big they are.)

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

+1 Stuart

", "time": "2023-03-28T01:05:19Z"}, {"author": "Gorry Fairhurst", "text": "

As a Chair: Good discussion, also we need to work on aggregating this traffic which might not be L4S (or some other CC)- and there is maths in the draft that need to be thought through. This likely can be discussed a little and I expect we'll make progress...

", "time": "2023-03-28T01:05:44Z"}, {"author": "Christian Huitema", "text": "

Most likely, the DSCp code point will be washed by the local router, what happens then?

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

So, NQB mark should be read as \"drop me first if there is in fact a queue\"

", "time": "2023-03-28T01:07:58Z"}, {"author": "Benson Muite", "text": "

Very interesting data

", "time": "2023-03-28T01:09:57Z"}, {"author": "Greg White", "text": "

@christian the draft recommends a \"traffic protection\" mechanism in the PHB. The recommended method is to monitor queue build up in the NQB queue, and selectively drop or reclassify (to Default) \"flows\" which are causing the queue.

", "time": "2023-03-28T01:15:54Z"}, {"author": "Chris Box", "text": "

Impressive to see how a drop in transmission rate can be avoided with a sufficiently rapid failover between paths.

", "time": "2023-03-28T01:19:54Z"}, {"author": "Martin Duke", "text": "

It looks good to me

", "time": "2023-03-28T01:21:21Z"}, {"author": "Ingemar Johansson", "text": "

Why the hurry with PS?. L4S is EXP and it is getting traction in 3GPP

", "time": "2023-03-28T01:26:51Z"}, {"author": "Gorry Fairhurst", "text": "

+1 read

", "time": "2023-03-28T01:28:01Z"}, {"author": "Martin Duke", "text": "

I am certainly fine with the whole document being EXP. The authors did not want that, and this was the compromise

", "time": "2023-03-28T01:28:22Z"}, {"author": "Chris Box", "text": "

I think the intention is that show of hands tool is for all participants, both remote and on site.

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

8 for; 12 against - of 89

", "time": "2023-03-28T01:30:17Z"}, {"author": "Bob Briscoe", "text": "

It did seem like more people voted than had read the doc

", "time": "2023-03-28T01:30:43Z"}, {"author": "Ingemar Johansson", "text": "

OK. My impression is that it took some extra work to explain outside the IETF that L4S as EXP is still useful, but once that work was done it was fine. I guess the same should apply also to MP-DCCP

", "time": "2023-03-28T01:32:26Z"}, {"author": "Magnus Westerlund", "text": "

Martin Duke, I don't really agree with your view of multipath in general being uncertain if it is safe. Don't we have quite some experience with MP-TCP for concurrent path usage?

", "time": "2023-03-28T01:32:36Z"}, {"author": "Martin Duke", "text": "

Sort of? People have done it, but we don't have a standards-track shared-bottleneck congestion control

", "time": "2023-03-28T01:33:36Z"}, {"author": "Martin Duke", "text": "

And has concurrency really been done for a wide set of use cases?

", "time": "2023-03-28T01:33:50Z"}, {"author": "Martin Duke", "text": "

I would not say that a transport protocol should be PS because it has shown to be safe for the specific case of SP tunnels. Are there other use cases that have lots of experience?

", "time": "2023-03-28T01:35:01Z"}, {"author": "Magnus Westerlund", "text": "

Maybe one work item for the WG that will not called Congress is to consider if the state of shared bottleneck congestion control can be advanced. I think it would be good to try to get the experience that might actually exist out in the open if possible.

", "time": "2023-03-28T01:37:18Z"}, {"author": "Martin Duke", "text": "

I agree!

", "time": "2023-03-28T01:37:28Z"}, {"author": "Louis Chan", "text": "

clarification on what I said on NQB. 1. without a min value of bw, it is not useful for application. e.g. Nx1Mbps might be a way. 2. wirless interface could varies down to few mbps in 2.4G. Suggest to limit the application to fixed line or min link speed as requirement

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

Specifying encryption without specifying key management? Really?

", "time": "2023-03-28T01:39:23Z"}, {"author": "Mirja K\u00fchlewind", "text": "

yes, these are kind of two independent things, both needed but there is no direct coupling

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

e.g you could use different key management for the same encryption

", "time": "2023-03-28T01:41:33Z"}, {"author": "Magnus Westerlund", "text": "

Christian I agree that this is a problem. There have been some use cases of TCP-AO where external keys kind of worked like in for routers protecting BGP. But I don't think the use cases for UDP options is as likely to have such situation that it makes sense.

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

Plus we already have DTLS for encrypting UDP. Why have two solutions?

", "time": "2023-03-28T01:45:06Z"}, {"author": "Magnus Westerlund", "text": "

Gorry, I will review the update and post a follow up on the mailing list.

", "time": "2023-03-28T01:45:18Z"}, {"author": "Greg White", "text": "

@Louis Chan On 1, I do agree that bw is likely more useful for an app developer. But, it seems that there is a lot of support for using % of path capacity so that the document can stay current. Are you ok with including the Mbps value today (whatever we determine that to be) as an informative statement? An app developer could presumably always have that number of fall back on if they aren't motivated to develop an understanding of what the current \"typical\" value would be.

", "time": "2023-03-28T01:47:32Z"}, {"author": "Magnus Westerlund", "text": "

Christian I would agree, for UDP that has so little functionality in the UDP layer compared to TCP the UDP level authentication is minor. The only functionality the UDP options auth does is that it authenticate the UDP options themselves. Otherwise the port, and checksum are implicitly protected by DTLS as anything that makes it into the right context and where the DTLS authenticaiton check succeeds are in the right context and not manipulated.

", "time": "2023-03-28T01:48:01Z"}, {"author": "Christian Huitema", "text": "

In any case, the draft for encryption should be created by a new WG in the security area, not as a quick hack in tsvwg.

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

Plus, we need a guarantee that if the app uses DTLS or QUIC, then it does not have to worry about the extra attack surface of UDP options.

", "time": "2023-03-28T01:48:57Z"}, {"author": "Magnus Westerlund", "text": "

Christian, I would think that Joe's answer is that the AUTH is very similar with TCP-AO. But having now worked on DTLS/SCTP I am worried what gremlins do hide in there. And it is impossible to review this properly as the AUTH option is not defined in a way that makes review simple and a gives a lot of guessing. And the security function needs combined work from security people and transport people. Either doing it alone is likely to result in security issues.

", "time": "2023-03-28T01:53:09Z"}, {"author": "Chris Box", "text": "

Martin your audio gain sounds too high.

", "time": "2023-03-28T01:58:01Z"}, {"author": "Louis Chan", "text": "

@Greg White Yes. It is just like IPv6 specifying a min packet size. When I said Nx1Mbps, it is about different classes. N=1 means class 1, and so on.

", "time": "2023-03-28T01:59:13Z"}, {"author": "Martin Duke", "text": "

Thanks Chris, switching to headphones

", "time": "2023-03-28T02:00:27Z"}, {"author": "Greg White", "text": "

@Louis Chan On 2, the draft doesn't define new application behaviors, only a new network behavior and a recommended DSCP for the application to use. On low rate links (well below \"typical\") the recommendation is to not support the PHB (and thus NQB-marked traffic goes in the Default queue).

", "time": "2023-03-28T02:01:11Z"}, {"author": "Randell Jesup", "text": "

I played with this when implementing the delay-based congestion control used in the Worldgate Ojo Videophone back in the 2004-2011 timeframe. We did a less-complex variation of this, with decaying knowledge of previous state

", "time": "2023-03-28T02:06:24Z"}, {"author": "Randell Jesup", "text": "

At the time, we found last-mile links were almost always our bottleneck, and those tended to be pretty stable in bandwidth available

", "time": "2023-03-28T02:07:48Z"}, {"author": "Magnus Westerlund", "text": "

Shouldn't careful resume be part of CCWG? This is a generic congestion control issue isn't it?

", "time": "2023-03-28T02:12:45Z"}, {"author": "Magnus Westerlund", "text": "

I do also support taking on this work in the IETF. I just wonder if TSVWG will be the right home when CCWG is created?

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

i've read it

", "time": "2023-03-28T02:13:39Z"}, {"author": "Gorry Fairhurst", "text": "

Read (author)

", "time": "2023-03-28T02:13:41Z"}, {"author": "John Border", "text": "

Yes

", "time": "2023-03-28T02:13:43Z"}, {"author": "J\u00f6rg Deutschmann", "text": "

I've read the draft

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

I read it

", "time": "2023-03-28T02:13:46Z"}, {"author": "Michael T\u00fcxen", "text": "

I've read it.

", "time": "2023-03-28T02:13:47Z"}, {"author": "Lucas Pardue", "text": "

Read

", "time": "2023-03-28T02:13:48Z"}, {"author": "Randell Jesup", "text": "

I have not read, but am familiar with the concept

", "time": "2023-03-28T02:14:01Z"}, {"author": "Tong Meng", "text": "

read

", "time": "2023-03-28T02:14:05Z"}, {"author": "Ingemar Johansson", "text": "

Have not read (yet)

", "time": "2023-03-28T02:14:16Z"}, {"author": "Randell Jesup", "text": "

@matt mathis - stuff from the last 10 years: RMCAT working group for realtime delay-sensitive congestion controls, for video/audio primarily

", "time": "2023-03-28T02:29:16Z"}, {"author": "Hang Shi", "text": "

Safe CC is important

", "time": "2023-03-28T02:29:27Z"}, {"author": "Christian Huitema", "text": "

ICCRG, for some of that and for outreach?

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

I think this is a good candidate to be part of 5033bis

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

but taking it around to groups like iccrg is fine

", "time": "2023-03-28T02:31:29Z"}, {"author": "Christian Huitema", "text": "

5033bis should definitely document all the ways Reno and Cubic fail the \"safe CC\" criteria...

", "time": "2023-03-28T02:31:57Z"}, {"author": "Martin Duke", "text": "

thanks chairs!

", "time": "2023-03-28T02:33:45Z"}, {"author": "Nicolas Kuhn", "text": "

Thanks!

", "time": "2023-03-28T02:33:51Z"}]