[{"author": "Andrew Campling", "text": "

You\u2019re a little quiet, perhaps lean in to the mic

", "time": "2024-03-20T23:33:37Z"}, {"author": "Jason Livingood", "text": "

Chairs could still be a touch louder IMO - some words still quite soft even in the room. (wake up I guess) ;-)

", "time": "2024-03-20T23:34:31Z"}, {"author": "Spencer Dawkins", "text": "

Just FYI, it's good for people to watch the notes, especially for a BOF with 55 minutes of discussion on the agenda. Please make sure the notes reflect what YOU said, at a minimum ...

", "time": "2024-03-20T23:35:20Z"}, {"author": "Cullen Jennings", "text": "

ack - we will try to be louder with the chair mic

", "time": "2024-03-20T23:35:47Z"}, {"author": "Ted Hardie", "text": "

I assume the same incentives drive LEO satellite operators, but I don't data on what they do here. Does anyone have data on that?

", "time": "2024-03-20T23:37:20Z"}, {"author": "Matt Joras", "text": "

A major recent LEO deployment does not currently shape, but they have been open with saying they're considering it.

", "time": "2024-03-20T23:38:09Z"}, {"author": "Ted Hardie", "text": "

Thanks, @Matt

", "time": "2024-03-20T23:38:32Z"}, {"author": "Jason Livingood", "text": "

I am skeptical of the claim of some big bandwidth shortage. There's ever more licensed spectrum being deployed and in any case in countries like the US, 70-90% of mobile bits go over WiFi (unlicensed).

", "time": "2024-03-20T23:42:52Z"}, {"author": "Brian Trammell", "text": "

the existence of actual bandwidth shortage is less important than the deployment of policing due to perceived bandwidth shortage, though...

", "time": "2024-03-20T23:43:40Z"}, {"author": "Matt Joras", "text": "

@Jason there's definitely a real problem with operators getting their CapEx curves under control due to the immense growth in video relative to the spectrum available.

\n

That said, like Brian says, not all operators due this just because of spectrum shortage, but for business reasons for a given subscriber.

", "time": "2024-03-20T23:44:10Z"}, {"author": "Jason Livingood", "text": "

Fair enough. Perception is not reality, Brian.

", "time": "2024-03-20T23:44:17Z"}, {"author": "Abhishek Tiwari", "text": "

Jason: Traffic shaping / policing in very prevalent in US mobile networks.

", "time": "2024-03-20T23:44:25Z"}, {"author": "Brian Trammell", "text": "

But it does drive purchasing decisions. :)

", "time": "2024-03-20T23:44:33Z"}, {"author": "Jason Livingood", "text": "

I definitely am aware of the US prevalence of rate shaping in mobile.

", "time": "2024-03-20T23:44:51Z"}, {"author": "Jason Livingood", "text": "

In the US, the upcoming FCC net neutrality rules (title-II) may bar the practice of rate shaping video or any other application or class of application.

", "time": "2024-03-20T23:44:55Z"}, {"author": "Chris Box", "text": "

And the EU's 2015 regulation makes it rare in Europe and the UK.

", "time": "2024-03-20T23:45:32Z"}, {"author": "Lucas Pardue", "text": "

Policing the police's ^^

", "time": "2024-03-20T23:45:34Z"}, {"author": "Jason Livingood", "text": "

@matt if MNOs have trouble building capacity, they can always slow down subscriber additions and they can also just shape on a per-user basis rather than per-application.

", "time": "2024-03-20T23:45:53Z"}, {"author": "Martin Thomson", "text": "

\"slow down subscriber additions\"?

", "time": "2024-03-20T23:46:14Z"}, {"author": "Matt Joras", "text": "

Video is a more obvious target to shape, because it has optionality in the application pattern, i.e. ABR

", "time": "2024-03-20T23:46:21Z"}, {"author": "David Schinazi", "text": "

Look at us, ruining everything with encryption, once again

", "time": "2024-03-20T23:46:35Z"}, {"author": "Matt Joras", "text": "

It also is by far the majority of the bits flowing through the network.

", "time": "2024-03-20T23:46:40Z"}, {"author": "Matt Joras", "text": "

Shaping/policing all types of traffic is much more noticeable and brutal on user experience, and you can tell when it happens.

", "time": "2024-03-20T23:47:26Z"}, {"author": "Martin Thomson", "text": "

actual utilization of a mobile network is only probabilistically related to subscriber load

", "time": "2024-03-20T23:47:27Z"}, {"author": "Dan Druta", "text": "

The shaping is not done per application. Is for ABR only irrespective of the app

", "time": "2024-03-20T23:47:30Z"}, {"author": "Lucas Pardue", "text": "

Im guessing the peak throughput of the watchers is variable to? So operators need to build to peak capacity requirements, which might have disproportionate costs

", "time": "2024-03-20T23:48:03Z"}, {"author": "Martin Duke", "text": "

I guess I don't understand why video is uniquely amenable to rate control

", "time": "2024-03-20T23:48:19Z"}, {"author": "David Schinazi", "text": "

It's the ABR

", "time": "2024-03-20T23:48:32Z"}, {"author": "Martin Duke", "text": "

but downloads are also elastic to the offered rate, no?

", "time": "2024-03-20T23:48:53Z"}, {"author": "Dan Druta", "text": "

It\u2019s not generic video. Adaptive video

", "time": "2024-03-20T23:49:11Z"}, {"author": "David Schinazi", "text": "

if video has limited bandwidth it will reduce the resolution, which is a property that doesn't apply to things like software updates

", "time": "2024-03-20T23:49:16Z"}, {"author": "Martin Duke", "text": "

the update will just take longer, which is just a differently bad QoE

", "time": "2024-03-20T23:49:40Z"}, {"author": "Ted Hardie", "text": "

@Martin it's because the video is being produced at multiple resolutions, which maps to multiple bits rates. If you police to below a specific bit rate, it adapts by selecting the lower resolution. It still gets the full content, but at a lower resolution.

", "time": "2024-03-20T23:49:50Z"}, {"author": "Kirill Pugin", "text": "", "time": "2024-03-20T23:50:24Z"}, {"author": "Alex Chernyakhovsky", "text": "

Video also needs to be \"realtime\". If you get less than 1 second/second you can't watch the video without stalls. Very few people care about variation in their download speed.

", "time": "2024-03-20T23:50:27Z"}, {"author": "Cullen Jennings", "text": "

Downloads are shaped many places too. The difference is that in the download case, the client does not need to try and guess the the rate.

", "time": "2024-03-20T23:50:29Z"}, {"author": "Spencer Dawkins", "text": "

Matt's slides will show video quality ladder (like, now). Video players can pick another rung on the ladder.

", "time": "2024-03-20T23:50:35Z"}, {"author": "Kirill Pugin", "text": "

for videos - it's quality, for other type of traffic it can be something else, like latency

", "time": "2024-03-20T23:50:47Z"}, {"author": "Jana Iyengar", "text": "

It's also the case that video applications track the quality of playbacks a LOT closer than software vendors track download delivery speeds. They're both tracked, but video quality is substantially more impactful to user experience.

", "time": "2024-03-20T23:51:18Z"}, {"author": "Mike Bishop", "text": "

Wasn't Brian's presentation first on the agenda?

", "time": "2024-03-20T23:51:27Z"}, {"author": "Kirill Pugin", "text": "

I guess the reason videos are targeted is that it's majority of the traffic

", "time": "2024-03-20T23:51:28Z"}, {"author": "Brian Trammell", "text": "

@mike: was also confused about that but honestly this is a better order.

", "time": "2024-03-20T23:51:56Z"}, {"author": "Jana Iyengar", "text": "

Video is the worst of all worlds: heavy on bandwidth consumption AND latency sensitive.

", "time": "2024-03-20T23:52:04Z"}, {"author": "Martin Duke", "text": "

the point is that the case for DPI is that clamping video is uniquely effective

", "time": "2024-03-20T23:52:11Z"}, {"author": "Dan Druta", "text": "

For background traffic like software updates if the network would know it would put it on a different radio scheduler

", "time": "2024-03-20T23:52:12Z"}, {"author": "Jason Livingood", "text": "

Re \"slow subscriber additions\" - I'm being a bit cute by saying if there is not enough supply (bandwidth) then reduce or slow growth of demand (users) until capacity is built.

", "time": "2024-03-20T23:52:23Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Martin Duke what do you mean DPI here? Everything is over QUIC/TLS

", "time": "2024-03-20T23:52:33Z"}, {"author": "Alex Chernyakhovsky", "text": "

Are you talking about SNI sniffing on the handshake and hoping it's accurate/not pooled?

", "time": "2024-03-20T23:52:54Z"}, {"author": "Martin Duke", "text": "

Marcus's talk was about sniffing SNI and doing other heuristics to identify ABR video

", "time": "2024-03-20T23:53:05Z"}, {"author": "Jason Livingood", "text": "

How is this not just a way for a certain type of network technology to under-invest in capacity? Why should the IETF help enable that?

", "time": "2024-03-20T23:53:15Z"}, {"author": "Mohamed Boucadair", "text": "

interesting to hear that we will get better performance with a adding a proxy. This gets us back to PEPs (RFC3135)

", "time": "2024-03-20T23:53:26Z"}, {"author": "Abhishek Tiwari", "text": "

Video is already 70-80% of overall internet traffic. This percentage is only going to increase. Even someone who may not be able to read, can infact consume video.

", "time": "2024-03-20T23:53:29Z"}, {"author": "Alex Chernyakhovsky", "text": "
\n

other heuristics

\n
\n

boo, just use anycast and work with the ISPs

", "time": "2024-03-20T23:53:43Z"}, {"author": "Dan Druta", "text": "

It\u2019s not a problem of suply. It\u2019s differentiation of offers for consumers

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

@Mohamed, I think the proxy is just for the experiment/PoC setup.

", "time": "2024-03-20T23:54:16Z"}, {"author": "Mike Bishop", "text": "

It's a way to ensure a particular box is on-path.

", "time": "2024-03-20T23:54:27Z"}, {"author": "Jason Livingood", "text": "

@mohamed interesting thought. Seems better to focus not on throttling but to do more creative cache placement & discovery

", "time": "2024-03-20T23:54:37Z"}, {"author": "Martin Duke", "text": "

\"work with the ISPs\" does not scale for small media providers

", "time": "2024-03-20T23:55:16Z"}, {"author": "Abhishek Tiwari", "text": "

Correct. Masque proxy was a way of getting results quickly to show that this is possible end-to-end. In no way this restricts the solution space.

", "time": "2024-03-20T23:55:17Z"}, {"author": "Spencer Dawkins", "text": "

Jason Livingood said:

\n
\n

Re \"slow subscriber additions\" - I'm being a bit cute by saying if there is not enough supply (bandwidth) then reduce or slow growth of demand (users) until capacity is built.

\n
\n

I suppose that bad user experience will slow NET subscriber additions ...

", "time": "2024-03-20T23:55:21Z"}, {"author": "Mohamed Boucadair", "text": "

the experiment can be run by locally configuring a bitrate

", "time": "2024-03-20T23:55:24Z"}, {"author": "Alex Chernyakhovsky", "text": "

small media providers probably won't get throttled

", "time": "2024-03-20T23:55:38Z"}, {"author": "Jason Livingood", "text": "

Why is video traffic any different from P2P traffic in 2007-2009? https://www.rfc-editor.org/rfc/rfc5594.html

", "time": "2024-03-20T23:56:22Z"}, {"author": "Jason Livingood", "text": "

After that P2P issue the IETF started LEDBAT, CDNI, and other WGs to address that more constructively than endorse using DPI or other methods to rate shape P2P traffic.

", "time": "2024-03-20T23:58:39Z"}, {"author": "Brian Trammell", "text": "

@jason: good point, that's what's happening here... the question is \"should we start a WG to address this particular problem more constructively that \"use DPI\"

", "time": "2024-03-20T23:59:35Z"}, {"author": "Brian Trammell", "text": "

especially because DPI was kinda still an an option in 2009, and it isn't today

", "time": "2024-03-20T23:59:58Z"}, {"author": "Jason Livingood", "text": "

Fair enough Brian. Just don't wanna see rate shaping of applications become normalized - I think it is a bad practice.

", "time": "2024-03-21T00:00:19Z"}, {"author": "Mohamed Boucadair", "text": "

I'm not sure that is binary Brian as supplying the bitrate won't prevent enforcing the shaping for these networks

", "time": "2024-03-21T00:00:24Z"}, {"author": "Mohamed Boucadair", "text": "

because of the handset trust

", "time": "2024-03-21T00:00:35Z"}, {"author": "Brian Trammell", "text": "

supplying the bitrate only works because the network actually can enforce the shaping, but now i'm giving spoilers for my slides :)

", "time": "2024-03-21T00:01:05Z"}, {"author": "Mohamed Boucadair", "text": "

ha ha ha

", "time": "2024-03-21T00:01:17Z"}, {"author": "Brian Trammell", "text": "

@jason: that's a good point that should come up again during discussion

", "time": "2024-03-21T00:01:43Z"}, {"author": "Jason Livingood", "text": "

Another approach may be that video streamers look at destination ASN (e.g. MNO X) and then shape the traffic they send to clients on that network.

", "time": "2024-03-21T00:03:23Z"}, {"author": "Lucas Pardue", "text": "

https://glasgowsprout.com/traditional-scottish-potato-scones/

", "time": "2024-03-21T00:03:24Z"}, {"author": "Martin Duke", "text": "

if framed as a client essentially requesting a fixed-rate circuit, this sounds OK to me

", "time": "2024-03-21T00:03:45Z"}, {"author": "Martin Duke", "text": "

it would be better than the operator trying to identify video and policing accordingly

", "time": "2024-03-21T00:04:18Z"}, {"author": "Brian Trammell", "text": "

...if y'all keep putting recipes in the chat i'm going to miss witarea...

", "time": "2024-03-21T00:04:23Z"}, {"author": "Mohamed Boucadair", "text": "

@Jason that would not work as this depends on the subscription

", "time": "2024-03-21T00:04:41Z"}, {"author": "Spencer Dawkins", "text": "

Jason Livingood said:

\n
\n

Fair enough Brian. Just don't wanna see rate shaping of applications become normalized - I think it is a bad practice.

\n
\n

In discussions we've had, we've been saying that we want to make traffic shaping unnecessary, but we recognize that if receivers don't adapt requested video rates themselves, operators will be doing either policing or shaping, because they don't have any other levers. Does that make sense?

", "time": "2024-03-21T00:04:47Z"}, {"author": "Jana Iyengar", "text": "

@brian, whatarea?

", "time": "2024-03-21T00:04:52Z"}, {"author": "Jason Livingood", "text": "

And these networks could also implement L4S so that this traffic would not affect latency-senstive traffic.

", "time": "2024-03-21T00:05:01Z"}, {"author": "Martin Duke", "text": "

the client should be free to have their video go in the general purpose lane, and I think this proposal could enable that

", "time": "2024-03-21T00:05:02Z"}, {"author": "Martin Duke", "text": "

?

", "time": "2024-03-21T00:05:02Z"}, {"author": "Brian Trammell", "text": "

:D

", "time": "2024-03-21T00:05:05Z"}, {"author": "Brian Trammell", "text": "

@martinduke: s/fixed-rate circuit/max-rate circuit (because there might be other dynamic bottlenecks on path) but yes.

", "time": "2024-03-21T00:05:48Z"}, {"author": "Ted Hardie", "text": "

@Jason I don't understand--are you assuming that the video traffic isn't latency sensitive?

", "time": "2024-03-21T00:05:53Z"}, {"author": "Spencer Dawkins", "text": "

Jason Livingood said:

\n
\n

And these networks could also implement L4S so that this traffic would not affect latency-senstive traffic.

\n
\n

I think we see L4S as a fine thing to do, and orthogonal to SCONEPRO.

", "time": "2024-03-21T00:06:03Z"}, {"author": "Lucas Pardue", "text": "

ABR techniques are already client driven. Server doesn't have much leeway to do anything itself. It's common for a manifest to be served from one origin and the media to be offloaded to other CDNs

", "time": "2024-03-21T00:06:03Z"}, {"author": "Jason Livingood", "text": "

@spencer that sentiment is very different from when rate shaping was done on P2P traffic, which was pitched as essentially the end of the world. ;-)

", "time": "2024-03-21T00:06:08Z"}, {"author": "Dan Druta", "text": "

@martin operators cannot identify ABR video accurately

", "time": "2024-03-21T00:06:25Z"}, {"author": "Jason Livingood", "text": "

@ted video is not as latency sensitive as Webex/Teams/Zoom/games

", "time": "2024-03-21T00:06:30Z"}, {"author": "Martin Duke", "text": "

I wish the IETF could acheive only 36% annoying

", "time": "2024-03-21T00:06:41Z"}, {"author": "Jonathan Lennox", "text": "

Red is blue plus orange?

", "time": "2024-03-21T00:07:12Z"}, {"author": "Ted Hardie", "text": "

@Jason You can have multi-resolution video in real time video (think the movement from postage stamp to main stage in a videocall).

", "time": "2024-03-21T00:07:34Z"}, {"author": "Martin Thomson", "text": "

The histogram is overlapping, rather than side-by-side, which is not great.

", "time": "2024-03-21T00:07:35Z"}, {"author": "Alan Frindell", "text": "

I think the colors got mixed up. In an early draft red+blue = purple

", "time": "2024-03-21T00:08:12Z"}, {"author": "Abhishek Tiwari", "text": "

Yeah Red is overlapping region

", "time": "2024-03-21T00:08:16Z"}, {"author": "Lucas Pardue", "text": "

flatten the curve!

", "time": "2024-03-21T00:08:26Z"}, {"author": "Lorenzo Miniero", "text": "

Simulcast and SVC are definitely used a lot in WebRTC real-time video

", "time": "2024-03-21T00:08:32Z"}, {"author": "Spencer Dawkins", "text": "

Jason Livingood said:

\n
\n

@spencer that sentiment is very different from when rate shaping was done on P2P traffic, which was pitched as essentially the end of the world. ;-)

\n
\n

Yes. We said that in https://datatracker.ietf.org/doc/html/rfc9317#name-peer-to-peer-applications.

", "time": "2024-03-21T00:08:56Z"}, {"author": "Brian Trammell", "text": "

wait, people wait six seconds for a stall to end without clicking away?

", "time": "2024-03-21T00:09:30Z"}, {"author": "Martin Thomson", "text": "

Brian: I think that this was machine driven

", "time": "2024-03-21T00:09:55Z"}, {"author": "Brian Trammell", "text": "

ah, that makes sense

", "time": "2024-03-21T00:10:22Z"}, {"author": "Jonathan Lennox", "text": "

Is this total over a video, or single bursts?

", "time": "2024-03-21T00:10:26Z"}, {"author": "Jason Livingood", "text": "

FWIW, many IETFers work for companies that have made filings in the FCC NN proceeding saying essentially that networks should not throttle specific apps, classes of apps, or protocols.

", "time": "2024-03-21T00:10:32Z"}, {"author": "Brian Trammell", "text": "

we can teach silicon to be patient as well as nervous

", "time": "2024-03-21T00:10:32Z"}, {"author": "Mike Bishop", "text": "

So 5 out of 200 seconds.

", "time": "2024-03-21T00:11:06Z"}, {"author": "Abhishek Tiwari", "text": "

The data presented here used a fixed playlist and a Facebook app where inter-swipe interval was automated

", "time": "2024-03-21T00:11:19Z"}, {"author": "Abhishek Tiwari", "text": "

Mike: Correct

", "time": "2024-03-21T00:11:57Z"}, {"author": "Mohamed Boucadair", "text": "

Abhishek, I guess you did the tests with non-GBR sessions. Were the same done GBR is used?

", "time": "2024-03-21T00:12:15Z"}, {"author": "Abhishek Tiwari", "text": "

Yes non-GBR sessions because this is how videos are delivered on real mobile networks

", "time": "2024-03-21T00:12:56Z"}, {"author": "Abhishek Tiwari", "text": "

non-GBR default bearer

", "time": "2024-03-21T00:13:19Z"}, {"author": "Andrew Campling", "text": "

Is it just me or are the sound levels from the room mics quite low?

", "time": "2024-03-21T00:14:02Z"}, {"author": "Carsten Bormann", "text": "

People need to eat the mikes

", "time": "2024-03-21T00:14:32Z"}, {"author": "Brian Trammell", "text": "

fwiw mike's levels are fine remote

", "time": "2024-03-21T00:14:42Z"}, {"author": "Nigel Hickson", "text": "

Yes agree Andrew

", "time": "2024-03-21T00:14:45Z"}, {"author": "Brian Trammell", "text": "

maybe my gain's way up

", "time": "2024-03-21T00:14:59Z"}, {"author": "Jason Livingood", "text": "

Netflix seems to be taking a different approach: https://sammy.brucespang.com/

", "time": "2024-03-21T00:15:04Z"}, {"author": "Ted Hardie", "text": "

2-3 being equal to 1 is not something I expected to be revealed today.

", "time": "2024-03-21T00:16:30Z"}, {"author": "Brian Trammell", "text": "

(speaking of gain, I apologize in advance for my levels, will be whispering into the mic to let the rest of the house sleep)

", "time": "2024-03-21T00:16:31Z"}, {"author": "Jonathan Hoyland", "text": "

Is this whole thing not just a huge layering violation?

", "time": "2024-03-21T00:16:54Z"}, {"author": "Lucas Pardue", "text": "

Did the experiment try streaming over TLS end-to-end

", "time": "2024-03-21T00:17:00Z"}, {"author": "Spencer Dawkins", "text": "

3 = 1, within engineering tolerances ... and that's why we're the iEtf ...

", "time": "2024-03-21T00:17:02Z"}, {"author": "Jonathan Lennox", "text": "

Clearly Jana is an astrophysicist

", "time": "2024-03-21T00:17:03Z"}, {"author": "Mike Bishop", "text": "

Plenty loud.

", "time": "2024-03-21T00:17:44Z"}, {"author": "Chris Lemmons", "text": "

Levels are perfect for remote.

", "time": "2024-03-21T00:17:47Z"}, {"author": "Spencer Dawkins", "text": "

Jonathan Hoyland said:

\n
\n

Is this whole thing not just a huge layering violation?

\n
\n

It's not intended to be. That's a great question for the mike.

", "time": "2024-03-21T00:17:49Z"}, {"author": "David Schinazi", "text": "

Brian, PLUS enthusiast

", "time": "2024-03-21T00:17:53Z"}, {"author": "Chris Lemmons", "text": "

The \"ask\" button is just to the left of the \"raise hand\" button. :)

", "time": "2024-03-21T00:18:24Z"}, {"author": "Alan Frindell", "text": "

Headed to Brian's for scones

", "time": "2024-03-21T00:18:31Z"}, {"author": "Mohamed Boucadair", "text": "

@Jonathan, there are already many bitrate limits that are supplied to the handset during the establishment of the network session. If a missing bitrate is needed, that would in theory supplied there as well. But that is the busness of 3GPP

", "time": "2024-03-21T00:18:52Z"}, {"author": "Mike Bishop", "text": "

Make me feel old.

", "time": "2024-03-21T00:19:10Z"}, {"author": "David Schinazi", "text": "

God it's been 8 years?

", "time": "2024-03-21T00:19:42Z"}, {"author": "Jason Livingood", "text": "

\"wait, haven't we been here before?\"

\n

https://www.cnet.com/tech/tech-industry/fcc-formally-rules-comcasts-throttling-of-bittorrent-was-illegal/

", "time": "2024-03-21T00:20:04Z"}, {"author": "Ted Hardie", "text": "

https://datatracker.ietf.org/wg/spud/about/

", "time": "2024-03-21T00:20:10Z"}, {"author": "Jonathan Lennox", "text": "

Half of it was pandemic time which doesn\u2019t count

", "time": "2024-03-21T00:20:12Z"}, {"author": "Ted Hardie", "text": "

Session protocol for UDP datagrams

", "time": "2024-03-21T00:20:16Z"}, {"author": "Spencer Dawkins", "text": "

David Schinazi said:

\n
\n

God it's been 8 years?

\n
\n

Speaking as the sponsoring AD, it seems like it was yesterday.

", "time": "2024-03-21T00:20:23Z"}, {"author": "Harald Alvestrand", "text": "

The facebook experiment says that when the middle box is the one that knows the availalble bandwidth, AND the end system has a secured & authenticated connection to the middle box, the problem can be solved. Aren't those the 2 points that make the problem difficult?

", "time": "2024-03-21T00:20:39Z"}, {"author": "Jana Iyengar", "text": "

Layering violations are where the best work happens

", "time": "2024-03-21T00:20:57Z"}, {"author": "Alex Chernyakhovsky", "text": "

It was not obvious to me why in the facebook experiment the middle box had to be an active participant to the session, rather than just control plane.

", "time": "2024-03-21T00:21:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

Was it there to just enforce you did not exceed the desired send rate?

", "time": "2024-03-21T00:21:34Z"}, {"author": "Jason Livingood", "text": "

Still relevant: https://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf

", "time": "2024-03-21T00:22:19Z"}, {"author": "Jason Livingood", "text": "

Clark et al, Tussle in Cyberspace

", "time": "2024-03-21T00:22:35Z"}, {"author": "Mohamed Boucadair", "text": "

+1 Alex. The handset can get directly the info for the PDU Session. Some modifications are needed though. The bitrate is not specific to an application but to all non-GBR ones

", "time": "2024-03-21T00:22:54Z"}, {"author": "Marcus Ihlar", "text": "

Alex, an on-path device has the capability to measure and enforce the bitrate.

", "time": "2024-03-21T00:23:00Z"}, {"author": "David Schinazi", "text": "

@Alex having the data path flow through the proxy allows the network to differentiate that traffic and treat it differently (rate limiting, zero-rating, etc)

", "time": "2024-03-21T00:23:07Z"}, {"author": "Abhishek Tiwari", "text": "

Alex: The middle box (mobile packet core network) is where the subscriber policy plan information is available. In how things are done today, this plan information is what triggers different kinds of shaping on different video flows. So the experiment was just demonstrating that instead of taking an hammer approach and shape the video flow on the network, tell the application what the limits are and let the application handle it in a way that does not hurt the user QOE.

", "time": "2024-03-21T00:24:34Z"}, {"author": "Spencer Dawkins", "text": "

Alex Chernyakhovsky said:

\n
\n

It was not obvious to me why in the facebook experiment the middle box had to be an active participant to the session, rather than just control plane.

\n
\n

This is only my opinion, but I THINK that what you're looking at is clearer on https://github.com/mjoras/SCONE-PROTOCL/blob/refarch/arch/ref-arch.md, but that was intended to be functional boxes, not actual devices.

", "time": "2024-03-21T00:24:38Z"}, {"author": "Alex Chernyakhovsky", "text": "

Right, but how many of those properties are _necessary_ to get the benefit? I don't like unnecessary proxies (yes, I am wearing a MASQUE hat, why do you ask?)

", "time": "2024-03-21T00:25:05Z"}, {"author": "Jonathan Hoyland", "text": "

Surely the place that needs to provide this data is the lowest bandwidth hop, and thus this helps iff that is the masque server?

", "time": "2024-03-21T00:25:07Z"}, {"author": "Mohamed Boucadair", "text": "

@david, does the proxy needs to access the SNI, for example?

", "time": "2024-03-21T00:25:27Z"}, {"author": "Spencer Dawkins", "text": "

Spencer Dawkins said:

\n
\n

Alex Chernyakhovsky said:

\n
\n

It was not obvious to me why in the facebook experiment the middle box had to be an active participant to the session, rather than just control plane.

\n
\n

This is only my opinion, but I THINK that what you're looking at is clearer on https://github.com/mjoras/SCONE-PROTOCL/blob/refarch/arch/ref-arch.md, but that was intended to be functional boxes, not actual devices.

\n
\n

If we move forward with the BOF after this meeting, comments and text are appreciated, of course.

", "time": "2024-03-21T00:25:34Z"}, {"author": "Mohamed Boucadair", "text": "

why do we need to disclose the app identity, then?

", "time": "2024-03-21T00:25:40Z"}, {"author": "Chris Box", "text": "

That last principle implies the MASQUE proxy would have to police any traffic exceeding the communicated rate.

", "time": "2024-03-21T00:26:06Z"}, {"author": "Mohamed Boucadair", "text": "

I do think it is too early to discuss whether this is PLUS like or not

", "time": "2024-03-21T00:26:30Z"}, {"author": "Jason Livingood", "text": "

Wasn't there a YouTube slide deck on the agenda?

", "time": "2024-03-21T00:26:31Z"}, {"author": "Brian Trammell", "text": "

or something it talks to, yes

", "time": "2024-03-21T00:26:31Z"}, {"author": "David Schinazi", "text": "

Matt mentioned that the MASQUE proxy wasn't a requirement, it was just a convenient tool to get a control channel next to your data channel

", "time": "2024-03-21T00:26:35Z"}, {"author": "Matt Joras", "text": "

@Mohamed because the policies operators want to apply are related to applications. So clients have to self-identify flows as video

", "time": "2024-03-21T00:26:40Z"}, {"author": "Lucas Pardue", "text": "

A ls masque client you indicated the target of the connection via a DNS name or IP address. There is no strong association to SNI and MASQUE does not speficiy anything related to SNI inspection of dataflows that are accepted

", "time": "2024-03-21T00:27:25Z"}, {"author": "Chris Box", "text": "

@David yes I get that. s/MASQUE proxy/network control point/

", "time": "2024-03-21T00:27:42Z"}, {"author": "Chris Box", "text": "

Unfortunately I have to head to ADD now so will catch up afterwards.

", "time": "2024-03-21T00:28:33Z"}, {"author": "Mohamed Boucadair", "text": "

@Lucas, I was puzzled then how differentiated mentioned by David can be enforced at the proxy. May be I misunderstood his comment

", "time": "2024-03-21T00:28:45Z"}, {"author": "Spencer Dawkins", "text": "

Removing a bottleneck will always reveal the next weakest link in the chain.

", "time": "2024-03-21T00:28:53Z"}, {"author": "Stephen Farrell", "text": "

yeah not clear how middlebox is authenticated to client in the general case

", "time": "2024-03-21T00:28:57Z"}, {"author": "Jonathan Lennox", "text": "

You will still need to do cc to identify any other bottleneck links, but real bottlenecks behave differently to shapers

", "time": "2024-03-21T00:29:32Z"}, {"author": "Matt Joras", "text": "

+1 Jonathan

", "time": "2024-03-21T00:29:47Z"}, {"author": "Alan Frindell", "text": "

At FB: shaping prevents us from coalescing photos and videos on the same connection

", "time": "2024-03-21T00:29:47Z"}, {"author": "Brian Trammell", "text": "

the architecture here works if the two choices for the sender are \"discover the shaper experimentally\" (i.e., by slamming your bandwidth curve into it, getting penalized for that, and then adapting) or \"discover the shaper explicity\" (via scone)

", "time": "2024-03-21T00:29:54Z"}, {"author": "Alan Frindell", "text": "

which interferes with prioitizaiton

", "time": "2024-03-21T00:29:59Z"}, {"author": "Mohamed Boucadair", "text": "

If there is no shaper or the shaper is suboptimal, then the problems mentioned by Markus does not apply anymore.

", "time": "2024-03-21T00:30:08Z"}, {"author": "Brian Trammell", "text": "

and discovering it experimentally kinda sucks for everyone involved

", "time": "2024-03-21T00:30:16Z"}, {"author": "Brian Trammell", "text": "

even with bbr

", "time": "2024-03-21T00:30:18Z"}, {"author": "Martin Thomson", "text": "

meetecho, it is a bit unfortunate that the notices for people joining the queue obscures the buttons that control the slides

", "time": "2024-03-21T00:30:33Z"}, {"author": "Lucas Pardue", "text": "

Re: differentiation, I'm guessing that the packet core \"figures it out\" according to their own thing

", "time": "2024-03-21T00:31:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

You have to support discovering the shaper experimentally anyway, because \"the shaper\" may not be a single box, but noisy neighbors/network conditions. And that will still suck.

", "time": "2024-03-21T00:32:05Z"}, {"author": "Alex Chernyakhovsky", "text": "

So it's not xor, it's and.

", "time": "2024-03-21T00:32:13Z"}, {"author": "Matt Joras", "text": "

To Jana's point: for at transport layer adaptation the rate we tell the CDN server to cap itself too is a MAXIMUM that a cngestion controller like BBR can achieve. So if BBR senses the bottleneck elsewhere, it will not just switch over to the maximum.

", "time": "2024-03-21T00:32:18Z"}, {"author": "Lorenzo Miniero", "text": "

@Martin Thomson ack, thanks for the feedback, we'll look into that! Notice that you can also advance slides with keyboard arrows, which may help in this case

", "time": "2024-03-21T00:32:31Z"}, {"author": "Matt Joras", "text": "

@Alex it's very very unusual to have multiple shapers empirically

", "time": "2024-03-21T00:33:07Z"}, {"author": "Matt Joras", "text": "

Actual paths are usually composed of \"normal\" queueing for the access technology and a single shaper/policer.

", "time": "2024-03-21T00:33:26Z"}, {"author": "Alex Chernyakhovsky", "text": "

If you restrict to CDN video delivery, sure. But if you're talking about connections that span multiple networks, it's not unlikely you went across multiple shapers.

", "time": "2024-03-21T00:33:57Z"}, {"author": "Martin Thomson", "text": "

NOTICE: Please keep comments to less than 60 seconds. Chairs will terminate fillibusters.

", "time": "2024-03-21T00:34:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

For Google's CDN we've seen shapers both between clients and our CDN nodes, and between our CDN nodes and upstream cache fill. It sucks.

", "time": "2024-03-21T00:34:29Z"}, {"author": "Alex Chernyakhovsky", "text": "

(and no, not the same shaper)

", "time": "2024-03-21T00:34:48Z"}, {"author": "Mohamed Boucadair", "text": "

I would add another question: is the IETF the right place to solve this (assuming there is a problem)

", "time": "2024-03-21T00:34:52Z"}, {"author": "Jonathan Hoyland", "text": "

@Alex Chernyakhovsky that's what I was assuming was the case

", "time": "2024-03-21T00:35:17Z"}, {"author": "Matt Joras", "text": "

Mohamed: yes, we unequivocally believe this is an IETF problem and not an SDO like 3GPP, and I will note we hae 3GPP participation.

", "time": "2024-03-21T00:35:24Z"}, {"author": "Martin Thomson", "text": "

@Lorenzo, I was trying to switch slides at that moment :)

", "time": "2024-03-21T00:35:30Z"}, {"author": "Mohamed Boucadair", "text": "

do you mean we have a formal request from 3GPP?

", "time": "2024-03-21T00:35:50Z"}, {"author": "Jonathan Hoyland", "text": "

How does this cope with coalesced connections?

", "time": "2024-03-21T00:35:55Z"}, {"author": "Carsten Bormann", "text": "

[Chairs: Please do not remove someone out of the queue who is actually speaking]

", "time": "2024-03-21T00:36:05Z"}, {"author": "Matt Joras", "text": "

Mohamed: no more that this is complementary to 3GPP work.

", "time": "2024-03-21T00:36:19Z"}, {"author": "Brian Trammell", "text": "

\"worked\" \"well\"

", "time": "2024-03-21T00:36:27Z"}, {"author": "Mohamed Boucadair", "text": "

Not sure what does that mean Mat

", "time": "2024-03-21T00:36:40Z"}, {"author": "Martin Thomson", "text": "

Carsten: ACK

", "time": "2024-03-21T00:36:44Z"}, {"author": "Marcus Ihlar", "text": "

Client opt-in is a core principle in the proposed charter.

", "time": "2024-03-21T00:37:31Z"}, {"author": "Jason Livingood", "text": "

Ted makes a nice point w/r/t ECN

", "time": "2024-03-21T00:38:36Z"}, {"author": "Brian Trammell", "text": "

+1 Ted, who is more awake than I am :)

", "time": "2024-03-21T00:38:40Z"}, {"author": "Jonathan Hoyland", "text": "

I'm curious also as to the intended security properties here. Who can add this signal, who can modify it, how is it enforced, etc.

", "time": "2024-03-21T00:38:43Z"}, {"author": "Jonathan Lennox", "text": "

Alex or anyone else: do you ever get more than one shaper per box participating in the flow (endpoint, CDN node, etc)?

", "time": "2024-03-21T00:39:43Z"}, {"author": "Mike Bishop", "text": "

+1 to Ted. ECN works because the network can drop your packets, and they're giving you an opportunity to react to the \"drop\" without having to recover the packet.

", "time": "2024-03-21T00:39:56Z"}, {"author": "Brian Trammell", "text": "

@jonathan: I'd actually want to see the intended security properties be explicit in the charter for a SCONE WG

", "time": "2024-03-21T00:39:57Z"}, {"author": "Cullen Jennings", "text": "

@Jonathan Hoyland see if the charter helps answer some of thoses questions for you (and agree they are key issues )

", "time": "2024-03-21T00:40:04Z"}, {"author": "Matt Joras", "text": "

@Jonathan Hoyland if you look at the draft charter and requirements documents, the idea is that encryption is done and only the client and the network device are able to communicate.

", "time": "2024-03-21T00:40:11Z"}, {"author": "Jonathan Lennox", "text": "

As a straw man

", "time": "2024-03-21T00:40:17Z"}, {"author": "Mike Bishop", "text": "

This is the same -- a box that can drop/delay your traffic will tell you under what circumstances that will occur.

", "time": "2024-03-21T00:40:20Z"}, {"author": "Jana Iyengar", "text": "

I take the MASQUE based approach as an example for demonstrating the value of network assistance. Different mechanism are definitely worth thinking about.

", "time": "2024-03-21T00:40:47Z"}, {"author": "Spencer Dawkins", "text": "

Mike Bishop said:

\n
\n

This is the same -- a box that can drop/delay your traffic will tell you under what circumstances that will occur.

\n
\n

Exactly.

", "time": "2024-03-21T00:40:50Z"}, {"author": "Brian Trammell", "text": "

+1 Tommy

", "time": "2024-03-21T00:41:04Z"}, {"author": "Matt Joras", "text": "

+1 Jana

", "time": "2024-03-21T00:41:20Z"}, {"author": "Jonathan Lennox", "text": "

I.e. as a straw man, each box has a MASQUE server it connects to

", "time": "2024-03-21T00:41:23Z"}, {"author": "Martin Thomson", "text": "

I think that MASQUE is a poor design for this. FWIW.

", "time": "2024-03-21T00:41:45Z"}, {"author": "Brian Trammell", "text": "

suggestion: reference 9419 as a source of principles in the charter

", "time": "2024-03-21T00:42:24Z"}, {"author": "Mohamed Boucadair", "text": "

Agree with Martin.

", "time": "2024-03-21T00:42:24Z"}, {"author": "Mike Bishop", "text": "

I don't think it's bad for a Masque server to have a way to send this signal, but I don't think adding a Masque server is a necessary step to achieve this.

", "time": "2024-03-21T00:42:24Z"}, {"author": "Ted Hardie", "text": "

@jonathan. That makes it much harder for a new entrant, it will tend to favor gatekeepers, so it is worth thinking careful about that design.

", "time": "2024-03-21T00:42:31Z"}, {"author": "Spencer Dawkins", "text": "

Jana Iyengar said:

\n
\n

I take the MASQUE based approach as an example for demonstrating the value of network assistance. Different mechanism are definitely worth thinking about.

\n
\n

I can't speak for the Facebook folks, but I understood their direction included \"what can we finish by IETF 119 and show that a solution could exist\".

", "time": "2024-03-21T00:42:32Z"}, {"author": "Jana Iyengar", "text": "

+1 @MT. Though it's fine to use it if it's one you want to build and use, we should build others that are more broadly usable.

", "time": "2024-03-21T00:42:48Z"}, {"author": "Abhishek Tiwari", "text": "

Spencer: +1

", "time": "2024-03-21T00:42:53Z"}, {"author": "Matt Joras", "text": "

Spencer has the right of it.

", "time": "2024-03-21T00:42:54Z"}, {"author": "Martin Thomson", "text": "

Can someone open an issue on the charter for RFC 9419 reference (Brian?)

", "time": "2024-03-21T00:42:55Z"}, {"author": "Brian Trammell", "text": "

on it

", "time": "2024-03-21T00:43:01Z"}, {"author": "Jana Iyengar", "text": "

We really should focus on the problem and not the MASQUE solution.

", "time": "2024-03-21T00:43:04Z"}, {"author": "Jonathan Hoyland", "text": "

What happens in the multi-middlebox case where multiple QUIC connections are being terminated and reestablished?

", "time": "2024-03-21T00:43:08Z"}, {"author": "Mirja K\u00fchlewind", "text": "

quic connection don't get terminated

", "time": "2024-03-21T00:43:37Z"}, {"author": "Matt Joras", "text": "

The existing charter focuses on QUIC.

", "time": "2024-03-21T00:43:40Z"}, {"author": "Mirja K\u00fchlewind", "text": "

because that would also mean terminating the TLS connection

", "time": "2024-03-21T00:43:52Z"}, {"author": "Pete Resnick", "text": "

@Jana Iyengar If we are not focused on MASQUE, does that mean that your answer to Q2 is \"maybe not yet\"?

", "time": "2024-03-21T00:44:02Z"}, {"author": "Mike Bishop", "text": "

@Mirja, but the CID can rotate and the port can change, so it's a different flow from the network's point of view.

", "time": "2024-03-21T00:44:14Z"}, {"author": "Jonathan Hoyland", "text": "

@Mirja K\u00fchlewind That's pretty much Cloudflare's main product

", "time": "2024-03-21T00:44:18Z"}, {"author": "Matt Joras", "text": "

We don't believe it 's approriate to have this information in the open since it can be a proxy for sensitive information, i.e. subscriber levels.

", "time": "2024-03-21T00:44:57Z"}, {"author": "Mirja K\u00fchlewind", "text": "

you have to identify the flow somehow; in case of masque it easy because the client opens the tunnel and routs the traffic explicitly there

", "time": "2024-03-21T00:45:06Z"}, {"author": "Jonathan Lennox", "text": "

You also need to discover the network box (masque server or otherwise) that you need to talk to

", "time": "2024-03-21T00:46:51Z"}, {"author": "Stephen Farrell", "text": "

@mirja how would a random client on a random n/w know where to find that masque server/proxy?

", "time": "2024-03-21T00:46:52Z"}, {"author": "Matt Joras", "text": "

TBD

", "time": "2024-03-21T00:47:06Z"}, {"author": "Stephen Farrell", "text": "

if the answer is TBD doesn't that imply the answer to Q2 on the slide is \"no\"?

", "time": "2024-03-21T00:47:34Z"}, {"author": "Ted Hardie", "text": "

@Stephen right now you'd do it with an anycast address, configured into the client or discovered via DNS, but there may be better options.

", "time": "2024-03-21T00:47:41Z"}, {"author": "Pete Resnick", "text": "

@meetecho (or whoever is in charge of such things) The volume of the floor mics is very low in the room.

", "time": "2024-03-21T00:47:42Z"}, {"author": "Matt Joras", "text": "

We don't believe so no. We think that's not the most pressing challenge and hence we didn't focus on it for the trial/POC.

", "time": "2024-03-21T00:48:01Z"}, {"author": "Jonathan Hoyland", "text": "

I think it's poor mic technique

", "time": "2024-03-21T00:48:18Z"}, {"author": "Mirja K\u00fchlewind", "text": "

in case of a mobile network, there is a bunch of signalling that could be used to provide the proxy information but I think we need also to have more generic approaches as Tommy indicated

", "time": "2024-03-21T00:48:19Z"}, {"author": "Jonathan Hoyland", "text": "

People need to kiss the mic

", "time": "2024-03-21T00:48:25Z"}, {"author": "Matt Joras", "text": "

@Stephen, we should not have the bar for \"understand the problem\" be \"we have a complete solution ready to go\"

", "time": "2024-03-21T00:48:34Z"}, {"author": "Lorenzo Miniero", "text": "

@Pete Resnick I'll notify the AV team

", "time": "2024-03-21T00:48:38Z"}, {"author": "Jana Iyengar", "text": "

@Pete: No, what I'm saying is that we should consider other solutions as well. I did say at the mic that I'm not convinced that we all agree on the problems down this path... but I feel good about out ability to find and solve the important ones.

", "time": "2024-03-21T00:48:42Z"}, {"author": "Jari Arkko", "text": "

Martin Thomson said:

\n
\n

Can someone open an issue on the charter for RFC 9419 reference (Brian?)

\n
\n

Thanks! This is needed. 8558, 9419, and Brian's excellent slide on the highly successful habits do all apply to this work.

", "time": "2024-03-21T00:49:01Z"}, {"author": "Jana Iyengar", "text": "

+1 Matt

", "time": "2024-03-21T00:49:29Z"}, {"author": "Brian Trammell", "text": "

https://github.com/mjoras/SCONE-PROTOCL/issues/60

", "time": "2024-03-21T00:49:32Z"}, {"author": "Mike Bishop", "text": "

@Jonathan, unless we're explicitly using the proxy, it's not necessary to locate the shaper, only to know it exists.

", "time": "2024-03-21T00:49:53Z"}, {"author": "Mike Bishop", "text": "

Or rather, it will find you.

", "time": "2024-03-21T00:50:05Z"}, {"author": "Jana Iyengar", "text": "

It's not RSVP. It's XCP.

", "time": "2024-03-21T00:50:31Z"}, {"author": "Jonathan Lennox", "text": "

If you\u2019re establishing a cryptographic context with it presumably you need to know what identity to expect

", "time": "2024-03-21T00:51:50Z"}, {"author": "Matt Joras", "text": "

My view on Lars' point: the operators are doing this anyway and there is NOTHING we can do to stop it.

\n

This gives us a way to give content endpoints and users a seat at the table.

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

Lars just found a new revenue stream for Mozilla

", "time": "2024-03-21T00:52:53Z"}, {"author": "Matt Joras", "text": "

At the end of the day it is their network.

", "time": "2024-03-21T00:53:00Z"}, {"author": "Jana Iyengar", "text": "

@Lars: Why can't operatros do this today?

", "time": "2024-03-21T00:53:03Z"}, {"author": "Stephen Farrell", "text": "

I don't think this gives users any seat - the cients here are e.g. specific video s/w not the end user

", "time": "2024-03-21T00:53:18Z"}, {"author": "Jonathan Hoyland", "text": "

Matt Joras said:

\n
\n

At the end of the day it is their network.

\n
\n

But they're just dumb pipes, right?

", "time": "2024-03-21T00:53:26Z"}, {"author": "Jana Iyengar", "text": "

@Jonathan: they are what regulation allows them to be. And regulation is VERY different in different parts of the world.

", "time": "2024-03-21T00:53:54Z"}, {"author": "Matt Joras", "text": "

+1 Jana and also a moving target

", "time": "2024-03-21T00:54:29Z"}, {"author": "Brian Trammell", "text": "

(and https://github.com/mjoras/SCONE-PROTOCL/pull/62 which adds 9419 at the bottom. also https://github.com/mjoras/SCONE-PROTOCL/pull/61 to start a bikeshed on the WG name)

", "time": "2024-03-21T00:54:32Z"}, {"author": "Jason Livingood", "text": "

@matt - many app/content companies are lobbying regulators and lawmakers to bar this practice (so I guess that is one thing they can & are doing)

", "time": "2024-03-21T00:54:43Z"}, {"author": "Jana Iyengar", "text": "

@Jason: that's only in the US and EU at best though.

", "time": "2024-03-21T00:55:02Z"}, {"author": "Matt Joras", "text": "

That's all well and good but I am not a lawyer, I am interested in technical solutions we can collaborate on and deploy.

", "time": "2024-03-21T00:55:06Z"}, {"author": "Jason Livingood", "text": "

@Jana very good point!

", "time": "2024-03-21T00:55:12Z"}, {"author": "Brian Trammell", "text": "

and actually the more I think about this Ted's parallel to ECN is extremely informative

", "time": "2024-03-21T00:55:31Z"}, {"author": "Jason Livingood", "text": "

@Matt you should ping ur regulatory affairs team ;-)

", "time": "2024-03-21T00:55:42Z"}, {"author": "Brian Trammell", "text": "

what we're proposing to build here is ELN (explicit limit notification)

", "time": "2024-03-21T00:55:47Z"}, {"author": "Matt Joras", "text": "

@Jason who is to say we have not :D

", "time": "2024-03-21T00:56:07Z"}, {"author": "Tara Tarakiyee", "text": "

Honest question: How is this not a net neutrality violation?

", "time": "2024-03-21T00:56:12Z"}, {"author": "Jason Livingood", "text": "

;-)

", "time": "2024-03-21T00:56:14Z"}, {"author": "Abhishek Tiwari", "text": "

Lucas: + 1 We need to coordinate with WebAPIs

", "time": "2024-03-21T00:56:30Z"}, {"author": "Mike Bishop", "text": "

I have no objection -- and in fact support -- the lobbying. But I also think that while this practice exists, a way to discover it has value.

", "time": "2024-03-21T00:56:30Z"}, {"author": "Jana Iyengar", "text": "

The regulatory environment in India, SAmerica, China are substantively different, and telcos have a lot more power for instance than content companies (because $reasons). We do live inside of regulatory spaces, so the question is not JUST technical. That said, regulation in this space remains weak, and operators have poor practices today. If this can make the user experience of the Internet better given the current world, it's worth doing. If this work becomes useless because regulation makes it so in the future, that's a risk we are always taking.

", "time": "2024-03-21T00:57:57Z"}, {"author": "Jason Livingood", "text": "

ISTM that this issue arises when a service is provisioned w/o a per-user overall bandwidth limit (e.g. 500 Mbps DS / 200 Mbps US) but more up to max avail capacity (common in many MNO plans). I wonder if the underlying problem is reduced by changing how the per-user service is configured/provisioned at the network layer.

", "time": "2024-03-21T00:57:58Z"}, {"author": "Mirja K\u00fchlewind", "text": "

it's not a net neutrality violation if the client/app agrees to it. Is shaping today a net neutrality violation is another question.

", "time": "2024-03-21T00:58:19Z"}, {"author": "Martin Thomson", "text": "

Chris: Here's a sketch:: ICMP

", "time": "2024-03-21T00:58:20Z"}, {"author": "Jari Arkko", "text": "

I won't join the mic queue, but for me the answers to the questions are: 1 YES, 2 YES, 3 YES and can contribute. Other comments that I would make when it comes to the discussion we've heard so far is that yes, watching extensibility and making the right calls there is important. I also don't think we should worry too much about trying to cover the talk-to-the-box-in-someone-wifi-network. I don't think we should try to solve all problems in the world or try to design something that's scalable for everything. Just fixing the current issue with throttling would have a major impact on user experience overall, for a large number of people.

", "time": "2024-03-21T00:58:39Z"}, {"author": "Martin Thomson", "text": "

To elaborate, a per-flow signal of a UDP datagram that is injected into the flow.

", "time": "2024-03-21T00:59:33Z"}, {"author": "Stephen Farrell", "text": "

@mt authenticated how?

", "time": "2024-03-21T00:59:58Z"}, {"author": "Mohamed Boucadair", "text": "

@Martin, the bitrate discussed so far is not per-flow. So, why \"injecting\" it on a per flow basis?

", "time": "2024-03-21T01:00:29Z"}, {"author": "Mike Bishop", "text": "

Right. As a strawman, an integrity-protected packet that a) proves it's on-path by echoing back something from a packet you sent, and b) includes a declaration of what traffic it intends to drop.

", "time": "2024-03-21T01:00:30Z"}, {"author": "Jana Iyengar", "text": "

authenticated ICMP sounds like a nice RFC to publish in 11 days.

", "time": "2024-03-21T01:00:43Z"}, {"author": "Lucas Pardue", "text": "

I forgot to say at the microphone but Suhas reminded me, indicating to the client the upload properties might be beneficial for other media use cases

", "time": "2024-03-21T01:00:47Z"}, {"author": "Chris Lemmons", "text": "

Less of a comment on this work and more of just making note of related work that might be of interest: https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5006-final.pdf

\n

(I know... a PDF. :) )

\n

The Common Media Server Data has a mechanism that allows an HTTP Proxy to add a response header with information about Max Suggested Bitrate. This is a similar \"layer-fuzzing\" situation and attempt to take on the same problem.

", "time": "2024-03-21T01:01:06Z"}, {"author": "Spencer Dawkins", "text": "

+1 Jeff Smith. It's not just proprietary per vendor, it's also proprietary per operator, so combinatorial for anyone who wants to use this in their media player.

", "time": "2024-03-21T01:01:49Z"}, {"author": "Martin Thomson", "text": "

Stephen: ICMP authenticates itself

", "time": "2024-03-21T01:01:53Z"}, {"author": "Mike Bishop", "text": "

The proxy is not a required component, only one approach.

", "time": "2024-03-21T01:02:50Z"}, {"author": "Jonathan Lennox", "text": "

ICMP proves it can see the traffic. Proving you can police the traffic is harder.

", "time": "2024-03-21T01:03:10Z"}, {"author": "Jana Iyengar", "text": "

I don't believe this is going to make shapers go away. This can help ISPs be better for users, but shapers and policers aren't going away.

", "time": "2024-03-21T01:03:44Z"}, {"author": "Jason Livingood", "text": "

Does this help ISPs avoid investing in growing capacity to meet demand growth?

", "time": "2024-03-21T01:04:11Z"}, {"author": "Jonathan Lennox", "text": "

But maybe in the kinds of networks we\u2019re talking about those are the same

", "time": "2024-03-21T01:04:14Z"}, {"author": "Tara Tarakiyee", "text": "

I don't really understand the \"better for users\" argument, sounds like it's just better for ISPs.

", "time": "2024-03-21T01:04:44Z"}, {"author": "Matt Joras", "text": "

@Tara it improves user experience for video objectively.

", "time": "2024-03-21T01:05:05Z"}, {"author": "Matt Joras", "text": "

the users are indeed choosing to watch the videos.

", "time": "2024-03-21T01:05:16Z"}, {"author": "Jason Livingood", "text": "

So does adding network capacity. ;-)

", "time": "2024-03-21T01:05:20Z"}, {"author": "Tara Tarakiyee", "text": "

improves the experience by artifically limiting the quality?

", "time": "2024-03-21T01:05:44Z"}, {"author": "Kirill Pugin", "text": "

@Tara, in a world that we are today, operators do do shaping and policing, self regulation provides better QoS to users

", "time": "2024-03-21T01:05:47Z"}, {"author": "Matt Joras", "text": "

@tara please see my data in the slides comparing the shaper vs. self-adaptation.

", "time": "2024-03-21T01:06:04Z"}, {"author": "Kirill Pugin", "text": "

@Tara quality already being limited by shaping

", "time": "2024-03-21T01:06:06Z"}, {"author": "Kirill Pugin", "text": "

just for video specific case, when ABR can be used - self regulation provides much better experience to end user

", "time": "2024-03-21T01:06:51Z"}, {"author": "Tara Tarakiyee", "text": "

@Kirill: That sounds like an issue, maybe not an IETF issue.

", "time": "2024-03-21T01:07:40Z"}, {"author": "Matt Joras", "text": "

can you elaborate why it is not an IETF issue?

", "time": "2024-03-21T01:08:01Z"}, {"author": "Jason Livingood", "text": "

capacity, capacity, capacity... :-)

", "time": "2024-03-21T01:08:05Z"}, {"author": "Tara Tarakiyee", "text": "

It's a telecom regulation and consumer rights issue. IETF doesn't do that afaik.

", "time": "2024-03-21T01:08:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "

managing network load is a technical problem

", "time": "2024-03-21T01:09:04Z"}, {"author": "Mike Bishop", "text": "

@Tara, the issue is that ABR will be attempting to increase bitrate, encountering the ceiling, dropping packets, and reducing bitrate. If the client can know the ceiling a priori and just not exceed it, then there are fewer drops and a better experience.

", "time": "2024-03-21T01:09:29Z"}, {"author": "Chris Lemmons", "text": "

Well, and network load can change suddenly for a variety of reasons.

", "time": "2024-03-21T01:09:31Z"}, {"author": "Jason Livingood", "text": "

@Mirja for sure. But if you keep table-topping your interfaces/nodes/whatever a good response is to segment those nodes, add interfaces, etc (eg add capacity)

", "time": "2024-03-21T01:10:36Z"}, {"author": "Tara Tarakiyee", "text": "

@Mirja: when it's about the content on the network, then it becomes more than a technical issue.

", "time": "2024-03-21T01:10:47Z"}, {"author": "Pete Resnick", "text": "

Thanks to whoever bumped up the volume of the floor mics!

", "time": "2024-03-21T01:11:15Z"}, {"author": "Mirja K\u00fchlewind", "text": "

if it is about threading different content providers differently it's political but that's not proposed

", "time": "2024-03-21T01:11:36Z"}, {"author": "Stephen Farrell", "text": "

Ted's idea seems like it needs a new auth mechanism

", "time": "2024-03-21T01:12:04Z"}, {"author": "Mirja K\u00fchlewind", "text": "

it's explicitly about a general solution that can be easily used for all/more content providers than today

", "time": "2024-03-21T01:12:06Z"}, {"author": "Lars Eggert", "text": "

@ted. sent ecn. not kidding

", "time": "2024-03-21T01:12:12Z"}, {"author": "Kazuho Oku", "text": "

+1 to Ted, at the same time I wonder if that should (or can) be encrypted and authenticated

", "time": "2024-03-21T01:12:33Z"}, {"author": "Jonathan Lennox", "text": "

Martin do you want to mention your icmp model at the mic?

", "time": "2024-03-21T01:12:37Z"}, {"author": "Martin Thomson", "text": "

Jonathan: Ted did a better job of that.

", "time": "2024-03-21T01:13:31Z"}, {"author": "Ted Hardie", "text": "

@Stephen Jana's point is that you don't have to know who is making the assertion, only that they have the power to make it so. That doesn't require Auth of the same type.

", "time": "2024-03-21T01:13:31Z"}, {"author": "Lars Eggert", "text": "

Would a solution where the shaper signals ECN to the video sender as the policed capacity is approached kinda work? No client changes involved.

", "time": "2024-03-21T01:13:57Z"}, {"author": "Stephen Farrell", "text": "

@ted isn't that a new auth mechanism then?

", "time": "2024-03-21T01:14:09Z"}, {"author": "Matt Joras", "text": "

Lars: short answer no, but I am in queue to address this at the mic

", "time": "2024-03-21T01:14:18Z"}, {"author": "Martin Thomson", "text": "

Lars: I've been waiting for someone to say \"L4S\"

", "time": "2024-03-21T01:14:19Z"}, {"author": "Jason Livingood", "text": "

L4S

", "time": "2024-03-21T01:14:52Z"}, {"author": "Jason Livingood", "text": "

;-)

", "time": "2024-03-21T01:14:59Z"}, {"author": "Kazuho Oku", "text": "

L4S (and we no longer need authentication or encryption)

", "time": "2024-03-21T01:15:07Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@lars: no, because the video experience is better if the server can throttle over a longer period than reacting immediately to a limited input

", "time": "2024-03-21T01:15:13Z"}, {"author": "Ted Hardie", "text": "

@Stephen I think it is a demonstration that you are on path, which is not usually considered auth. I think I am making the same point as MT was in his ICMP example.

", "time": "2024-03-21T01:15:28Z"}, {"author": "Gorry Fairhurst", "text": "

@lars - maybe at thge transport - but is this a session level signal, on a different time granuality?

", "time": "2024-03-21T01:15:38Z"}, {"author": "Jana Iyengar", "text": "

@Stephen, perhaps? It's different than what we would call authentication though; the endpoint doesn't need to know who the network element is, just that it can write to packets

", "time": "2024-03-21T01:16:03Z"}, {"author": "Christopher Inacio", "text": "

Was the answer that applications can now see your network provider subscription information / performance details? (I mean that sounds like A M A Z I N G marketing information to capture.

", "time": "2024-03-21T01:16:27Z"}, {"author": "Brian Trammell", "text": "

it's not ECN++, it's AccECN++ ++

", "time": "2024-03-21T01:16:32Z"}, {"author": "Ted Hardie", "text": "

I agree with Matt; this is a different signal, not a congestion signal. But ECN shows us that passing that through the network is tractable.

", "time": "2024-03-21T01:16:35Z"}, {"author": "Jonathan Lennox", "text": "

ECN is \u201cI can modify your packets\u201d which is stronger than ICMP \u201cI can see your packets \u201c

", "time": "2024-03-21T01:16:39Z"}, {"author": "David Schinazi", "text": "

no no Brian it's ECN PLUS PLUS

", "time": "2024-03-21T01:16:47Z"}, {"author": "Stephen Farrell", "text": "

so an unauthenticated (in the crypto sense) on-path signal from anyone on-path may be enough for this ?

", "time": "2024-03-21T01:16:55Z"}, {"author": "Jana Iyengar", "text": "

as it is for ECN, it should be

", "time": "2024-03-21T01:17:25Z"}, {"author": "Matt Joras", "text": "

+1 Ted

", "time": "2024-03-21T01:17:28Z"}, {"author": "Jason Livingood", "text": "

If someone had told me in 2008 that the IETF was trying to standardize protocol-specific throttling because it is a pervasive practice and we should just support it I would have told them they were insane. ;-)

\n

But I guess I am also a realist and I get that different markets have different technical constraints..

", "time": "2024-03-21T01:17:35Z"}, {"author": "Luis Contreras", "text": "

Regarding what MAtt just said at the mic: maybe good to differetiate what are the problems solved by ECN and what not, and then concentrate on those

", "time": "2024-03-21T01:18:02Z"}, {"author": "Eric Kinnear", "text": "

Matt: On one hand this isn't a \"congestion\" signal, but it _is_ a signal about the capacity of the bottleneck, even if that bottleneck is artificial, no?

", "time": "2024-03-21T01:18:02Z"}, {"author": "Christopher Inacio", "text": "

aye, aye - I'm still wondering about multipath, which seems weakly draft in the existing draft.

", "time": "2024-03-21T01:18:05Z"}, {"author": "Jonathan Lennox", "text": "

Though there\u2019s also the question of whether this throttle information needs to be private from other on-path observers

", "time": "2024-03-21T01:18:20Z"}, {"author": "Brian Trammell", "text": "

if you end up in a multipath situation where you have different policers on each path you're going to have a bad day no matter what

", "time": "2024-03-21T01:18:37Z"}, {"author": "Jana Iyengar", "text": "

I think this IS about congestion. We may not like the name ECN+++, but it's pretty darn close

", "time": "2024-03-21T01:18:41Z"}, {"author": "Kazuho Oku", "text": "

Both ECN and this proposal is same in sense that it is saying \"I will punish you if you use more bandwidth than X.\"

", "time": "2024-03-21T01:18:50Z"}, {"author": "Lucas Pardue", "text": "

proxies can discover their proxies and pass that information to the end hosts

", "time": "2024-03-21T01:18:54Z"}, {"author": "Ted Hardie", "text": "

@Jason we're not trying to standardize the throttling, we're suggesting we standardize the signal that informs the application that it is happening. That's not quite the same thing, at least to me.

", "time": "2024-03-21T01:19:17Z"}, {"author": "Jonathan Hoyland", "text": "

What happens with multipath?

", "time": "2024-03-21T01:19:20Z"}, {"author": "Stephen Farrell", "text": "

FWIW, I don't thnik that conversaion convinced me that the answer to #2 is yes

", "time": "2024-03-21T01:19:20Z"}, {"author": "Jonathan Lennox", "text": "

(I.e. \u201cwhich data plan am I subscribed to\u201d is private information)

", "time": "2024-03-21T01:19:37Z"}, {"author": "Jana Iyengar", "text": "

multipath is multiple single paths

", "time": "2024-03-21T01:19:37Z"}, {"author": "Jason Livingood", "text": "

BTW operators are also like 'hey seeing FQDN in TLS setup is useful for parental controls' and is extremely pervasive but at the same time we are pushing ahead on ECH.

", "time": "2024-03-21T01:19:46Z"}, {"author": "Matt Joras", "text": "

Eric: yes, though for example for some operators they would be okay with NO transport layer adaptation involved at all, and just having the application cap quality, and let the congestion control use the network organically

", "time": "2024-03-21T01:19:53Z"}, {"author": "Jonathan Hoyland", "text": "

@Jana Iyengar But they might not be totally distinct

", "time": "2024-03-21T01:20:26Z"}, {"author": "Matt Joras", "text": "

that's why I want to make it clear that this isn't just \"the congestion controller has to have more information to do better\"

", "time": "2024-03-21T01:20:32Z"}, {"author": "Jonathan Lennox", "text": "

Countermeasures for SNI are possible. Countermeasures for shaping aren\u2019t (technically).

", "time": "2024-03-21T01:21:04Z"}, {"author": "Brian Trammell", "text": "

actually the name ECN+++ is kind of growing on me

", "time": "2024-03-21T01:21:13Z"}, {"author": "Eric Kinnear", "text": "
\n

NO transport layer adaptation involved at all, and just having the application cap quality

\n
", "time": "2024-03-21T01:21:27Z"}, {"author": "Eric Kinnear", "text": "

Can they trust that?

", "time": "2024-03-21T01:21:32Z"}, {"author": "Brian Trammell", "text": "

it has the advantage of not making me hungry though

", "time": "2024-03-21T01:21:40Z"}, {"author": "Matt Joras", "text": "

They're willing to today. And OEMs can give them a way to \"trust but verify\"

", "time": "2024-03-21T01:21:47Z"}, {"author": "Matt Joras", "text": "

We CAN play cat and mouse with shpaers today. We choose not to because it is hostile

", "time": "2024-03-21T01:22:00Z"}, {"author": "Matt Joras", "text": "

I just need to change the QUIC version and bye bye shaping until they notice.

", "time": "2024-03-21T01:22:19Z"}, {"author": "Jana Iyengar", "text": "

@Jonathan: yes, yes, and you can do MPTCP-like CC. There's definitely work this creates for the network elements and endpoints

", "time": "2024-03-21T01:22:28Z"}, {"author": "Mohamed Boucadair", "text": "

I replied no because I'm not sure yet why a per flow signal is needed here and that

", "time": "2024-03-21T01:22:47Z"}, {"author": "Brian Trammell", "text": "

are there people running multipath where those paths have different shapers on them?

", "time": "2024-03-21T01:23:22Z"}, {"author": "Mohamed Boucadair", "text": "

PDU Session configuration at the 3GPP would be more reasnable given that the main case mentioned here is related to cellular

", "time": "2024-03-21T01:23:28Z"}, {"author": "Brian Trammell", "text": "

it seems like that'd break badly enough that you'd just stop trying to do it

", "time": "2024-03-21T01:23:48Z"}, {"author": "Matt Joras", "text": "

@Mohamed we want to solve this for satellite as well

", "time": "2024-03-21T01:24:11Z"}, {"author": "Matt Joras", "text": "

there's no 3GPP there :)

", "time": "2024-03-21T01:24:19Z"}, {"author": "Lucas Pardue", "text": "

i don't think there is a multipath problem unique to this. Actually leveraging multipath QUIC is going tob e complex for apps whatever they try to do

", "time": "2024-03-21T01:24:32Z"}, {"author": "Mohamed Boucadair", "text": "

there, but that's another story

", "time": "2024-03-21T01:24:43Z"}, {"author": "Matt Joras", "text": "

+1 Lucas, I think acting as if we have solved the multipath problem is quite funn

", "time": "2024-03-21T01:24:51Z"}, {"author": "Jonathan Lennox", "text": "

Multipath between Wi-Fi and mobile is very likely

", "time": "2024-03-21T01:25:02Z"}, {"author": "Gorry Fairhurst", "text": "

... sometimes there is 3GPP in satellite (aka NTN), but the endpoint might not be the terminal.

", "time": "2024-03-21T01:25:06Z"}, {"author": "Mohamed Boucadair", "text": "

For that one Jonathan, there is ATSSS in place and policing can be shared with an UPF

", "time": "2024-03-21T01:25:45Z"}, {"author": "Mohamed Boucadair", "text": "

However, we don't need to inherit the complexities of ATSSS for this simple signal

", "time": "2024-03-21T01:26:08Z"}, {"author": "Lucas Pardue", "text": "

its only likely if apps implement multipath QUIC. And today I'm not hearing they do at any scale that this room can understand the full complexity space.

", "time": "2024-03-21T01:26:11Z"}, {"author": "Brian Trammell", "text": "

+1, this was worth being awake for :)

", "time": "2024-03-21T01:26:17Z"}, {"author": "Brian Trammell", "text": "

thanks all

", "time": "2024-03-21T01:26:20Z"}, {"author": "Jana Iyengar", "text": "

I think the multipath problem is just one of the things worth considering, and there's going to be some interesting things to solve at the network element. I would argue that multipath isn't specifically harder than the other issues.

", "time": "2024-03-21T01:26:23Z"}, {"author": "Chris Lemmons", "text": "

Time to go bake some scones.

", "time": "2024-03-21T01:26:32Z"}]