[{"author": "Jon Varsanik", "text": "

Impressive work in the hackathon!

", "time": "2025-07-22T12:48:44Z"}, {"author": "Sanjay Mishra", "text": "

Agree with Jon and kudos to all who spent the weekend \"sconing\"

", "time": "2025-07-22T12:51:20Z"}, {"author": "Daniel Gillmor", "text": "

should i have seen the word \"tonnage\" in this context before? it's new to me.

", "time": "2025-07-22T12:53:03Z"}, {"author": "Matt Joras", "text": "

@Daniel Gillmor it basically means \"amount of data\", it is operator jargon

", "time": "2025-07-22T12:54:15Z"}, {"author": "Daniel Gillmor", "text": "

does it just mean \"throughput\"?

", "time": "2025-07-22T12:54:19Z"}, {"author": "Daniel Gillmor", "text": "

ok, thanks, Matt!

", "time": "2025-07-22T12:54:34Z"}, {"author": "Matt Joras", "text": "

Shipping bytes instead of shipping cargo, essentially :smile:

", "time": "2025-07-22T12:54:55Z"}, {"author": "Daniel Gillmor", "text": "

sure, but i don't know how many bytes per ton

", "time": "2025-07-22T12:55:13Z"}, {"author": "Daniel Gillmor", "text": "

;)

", "time": "2025-07-22T12:55:17Z"}, {"author": "Benjamin Schwartz", "text": "

What is the expectation if the client does not conform to the advised limits?

", "time": "2025-07-22T12:55:25Z"}, {"author": "Brian Trammell", "text": "

the policer is still there.

", "time": "2025-07-22T12:56:10Z"}, {"author": "Matt Joras", "text": "

\"Networks are going to do what networks are going to do\" -- i.e. it is CSP discretion. They could, for example, go back to destructive shaping/throttling.

", "time": "2025-07-22T12:56:14Z"}, {"author": "Brian Trammell", "text": "

and will do what policers do.

", "time": "2025-07-22T12:56:16Z"}, {"author": "Christian Huitema", "text": "

This is an american unit. Ton, Kiloton, Megaton, Fuctton...

", "time": "2025-07-22T12:56:36Z"}, {"author": "Daniel Gillmor", "text": "

i mean, the policer might still limit traffic further, if its predictions about capacity turn out to be wrong

", "time": "2025-07-22T12:56:53Z"}, {"author": "Benjamin Schwartz", "text": "

OK, but are these meant to be shaper parameters? Or is this meant to trigger a phone call to the app's NOC?

", "time": "2025-07-22T12:57:09Z"}, {"author": "Brian Trammell", "text": "

shaper params

", "time": "2025-07-22T12:57:21Z"}, {"author": "Jon Varsanik", "text": "

But it is a good question (how do operators monitor for compliance) - I think Anoop will mention - will this be real-time? Over an entire day? Also not totally clear to me.

", "time": "2025-07-22T12:57:23Z"}, {"author": "Daniel Gillmor", "text": "

@Ben i think the intent is for the application to request adjusted throughput from its peer

", "time": "2025-07-22T12:57:48Z"}, {"author": "Daniel Gillmor", "text": "

(so that's done at the application layer)

", "time": "2025-07-22T12:57:57Z"}, {"author": "Matt Joras", "text": "

We actually have a recent PR on this topic as for \"how to achieve compliance\": https://github.com/ietf-wg-scone/scone/pull/40

", "time": "2025-07-22T12:58:38Z"}, {"author": "Brian Trammell", "text": "

@jon: there's a discussion of an open issue in the next session about exactly this, and this experimentation deeds into that

", "time": "2025-07-22T12:58:46Z"}, {"author": "Brian Trammell", "text": "

feeds even

", "time": "2025-07-22T12:58:50Z"}, {"author": "Matt Joras", "text": "

As for \"how to measure for compliance\", that's indeed what some of this discussion is about.

", "time": "2025-07-22T12:58:59Z"}, {"author": "Jon Varsanik", "text": "

+1 TY

", "time": "2025-07-22T13:00:00Z"}, {"author": "Benjamin Schwartz", "text": "

OK, so this falls under this text:

\n
\n

when a network element detects a flow using more bandwidth than advertised via
\nSCONE, it might switch to applying its policies for non-SCONE flows, using
\ncongestion control signals.

\n
\n

So there might or might not be a shaper in place with these parameters. :thinking:

", "time": "2025-07-22T13:02:28Z"}, {"author": "Brian Trammell", "text": "

this falls under the heading of \"credible threat of network violence\", per the original BoF requirements

", "time": "2025-07-22T13:03:49Z"}, {"author": "Matt Joras", "text": "

Correct. There's also actually a incompatibility with what we are specifying here and how shapers are configured. They aren't configured with e.g. \"60s window\", they're configured with other parameters like burst size, desired rates, etc.

", "time": "2025-07-22T13:04:10Z"}, {"author": "Daniel Gillmor", "text": "

17 seconds to review the results slide \u2639

", "time": "2025-07-22T13:04:44Z"}, {"author": "Daniel Gillmor", "text": "

an app-dependent setting would be an additional privacy problem.

", "time": "2025-07-22T13:06:55Z"}, {"author": "Chris Box", "text": "

The part I'm missing is why the duration has to be the max of the values in the table, rather than letting it be some function of the advised bitrate.

", "time": "2025-07-22T13:08:30Z"}, {"author": "Daniel Gillmor", "text": "

for a 2Mbps stream, a window of 120s means 240Mbits, or 30MB

", "time": "2025-07-22T13:08:47Z"}, {"author": "Daniel Gillmor", "text": "

i think what Mo is asking is \"are we ok with letting a client download 30 MB in the first second of 120sec?\"

", "time": "2025-07-22T13:09:22Z"}, {"author": "Chris Box", "text": "

It's ok with me

", "time": "2025-07-22T13:09:31Z"}, {"author": "Brian Trammell", "text": "

(that's how I understand it yes)

", "time": "2025-07-22T13:09:36Z"}, {"author": "Chris Box", "text": "

And I run a mobile network

", "time": "2025-07-22T13:09:46Z"}, {"author": "Daniel Gillmor", "text": "

Chris, can you say that at the mic?

", "time": "2025-07-22T13:09:59Z"}, {"author": "Chris Box", "text": "

Queue is closed

", "time": "2025-07-22T13:10:14Z"}, {"author": "Daniel Gillmor", "text": "

if the shaper attacks your traffic after you complied, then why should you bother complying?

", "time": "2025-07-22T13:11:04Z"}, {"author": "Brian Trammell", "text": "

queue unlocked for chris

", "time": "2025-07-22T13:11:39Z"}, {"author": "Daniel Gillmor", "text": "

the impedance mismatch between the actual shaper's window and the advertised window does seem like a operational concern.

", "time": "2025-07-22T13:14:54Z"}, {"author": "Jon Varsanik", "text": "

Good question about the amount of rsources needed to monitor compliance - is it more costly to keep memory over 120s or to chack clompliance more often?

", "time": "2025-07-22T13:15:11Z"}, {"author": "Matt Joras", "text": "

In practice we expect that the \"monitoring\" and the shaper are going to be separately configured entities

", "time": "2025-07-22T13:15:23Z"}, {"author": "Martin Thomson", "text": "

This question does relate to how long you have to wait until you put the shaper/policer in place.

", "time": "2025-07-22T13:15:30Z"}, {"author": "Matt Joras", "text": "

since the methodology for shaping and \"measuring\" in this case are quite different

", "time": "2025-07-22T13:15:35Z"}, {"author": "Martin Thomson", "text": "

Jon: the state requirement for monitoring is very low. There is an algorithm in the draft PR: https://github.com/ietf-wg-scone/scone/pull/37

", "time": "2025-07-22T13:16:32Z"}, {"author": "Daniel Gillmor", "text": "

Matt: but surely you need to align them in some way, right? the goal is to incentivize compliance with the advertised rate, and presumably the incentive is that you won't get hit by Trammell's \"network violence\".

", "time": "2025-07-22T13:16:34Z"}, {"author": "Matt Joras", "text": "

@Daniel Gillmor so in practice the shapers are configured to meet a certain \"higher level goal\", like \"achieve this tonnage for this application\". The configuration falls out of that.

\n

We expect that the throughput advice will be the same way, i.e. \"What throughput advice do I need to set to achieve my tonnage goals\".

\n

So we think they will be aligned from that high level, but not on any lower level, since the methods are quite different. Does that make sense?

", "time": "2025-07-22T13:17:59Z"}, {"author": "Chris Box", "text": "

@Marting Agree - having now looked at PR 37 algorithm it seems clear that the state requirement is very small. So that appears to remove my concern re core network resource increasing with time duration.

", "time": "2025-07-22T13:21:59Z"}, {"author": "Chris Box", "text": "

s/Marting/Martin

", "time": "2025-07-22T13:22:10Z"}, {"author": "Daniel Gillmor", "text": "

the window discussion makes me nervous. if we agree that the overall goal is 2Mbps, but we're not aligned on the window, then me bursting 30MB in the first two seconds might hit the shaper anyway.

", "time": "2025-07-22T13:22:28Z"}, {"author": "Chris Box", "text": "

Not if the shaper is located in a SCONE-aware node

", "time": "2025-07-22T13:23:04Z"}, {"author": "Daniel Gillmor", "text": "

Chris, you mean the shaper is actually aligned on the window size

", "time": "2025-07-22T13:23:23Z"}, {"author": "Chris Box", "text": "

Yes

", "time": "2025-07-22T13:23:33Z"}, {"author": "Daniel Gillmor", "text": "

but Matt is saying that he doesn't think that this alignment will necessarily happen.

", "time": "2025-07-22T13:23:42Z"}, {"author": "Chris Box", "text": "

That would seem to be a broken implementation of SCONE

", "time": "2025-07-22T13:24:04Z"}, {"author": "Daniel Gillmor", "text": "

i agree, but i'm reading Matt as disagreeing

", "time": "2025-07-22T13:24:30Z"}, {"author": "Wesley Eddy", "text": "

Maybe something getting confused is that the actual rates on small timescales are determined by congestion control. Scone guidance is for selecting appropriate media options at macro scale, which is why it\u2019s appropriate to check at macro scale.

", "time": "2025-07-22T13:24:35Z"}, {"author": "Sanjay Mishra", "text": "

Daniel, also to clarify, the goal for a mobile operator is to not keep all flows at 2Mbps. The user plans (at least in the US, allows mobile subscribers with plans to go as as high at 4Mbps, and as high as 10Mbps

", "time": "2025-07-22T13:24:54Z"}, {"author": "Daniel Gillmor", "text": "

and the shaper operates at which scale?

", "time": "2025-07-22T13:24:55Z"}, {"author": "Sanjay Mishra", "text": "

As I understand the time window is how long an enforcement is deferred \"to allow time to the application\" to follow the advised bit-rate\" commensurate with their plans and the current radio conditions

", "time": "2025-07-22T13:26:09Z"}, {"author": "Wesley Eddy", "text": "

Shapers at micro scale could be relaxed if the macro scale \u201ctonnage\u201d is controlled effectively by the app.

", "time": "2025-07-22T13:26:13Z"}, {"author": "Martin Duke", "text": "

Is the indication not in the crypto envelope?

", "time": "2025-07-22T13:26:44Z"}, {"author": "Matt Joras", "text": "

No, that's the whole point, it is on the requirements slide. It is to avoid the network element doing DPI and trial decryption

", "time": "2025-07-22T13:27:12Z"}, {"author": "Martin Thomson", "text": "

Detecting video flows is NOT a goal I support

", "time": "2025-07-22T13:28:29Z"}, {"author": "Benjamin Schwartz", "text": "

Does the indication mean \"I will comply with the SCONE advice\"?

", "time": "2025-07-22T13:29:07Z"}, {"author": "Martin Thomson", "text": "

For the chairs, I have a choice of a 1 Euro coin or a Canadian dime if we get to that point.

", "time": "2025-07-22T13:29:12Z"}, {"author": "Martin Thomson", "text": "

Ben: nope

", "time": "2025-07-22T13:29:18Z"}, {"author": "David Schinazi", "text": "

How is this supposed to work without breaking servers that don't support SCONE?

", "time": "2025-07-22T13:29:25Z"}, {"author": "Daniel Gillmor", "text": "

putting any explicit distinguishing signalling on the outside of the encrypted packet is automatically a cost. please avoid doing that where possible.

", "time": "2025-07-22T13:29:30Z"}, {"author": "Martin Thomson", "text": "

It means that you won't choke if someone sends you a SCONE packet.

", "time": "2025-07-22T13:29:40Z"}, {"author": "Daniel Gillmor", "text": "

i also have coins here in brooklyn, but you'd have to trust me on the flip

", "time": "2025-07-22T13:30:02Z"}, {"author": "Benjamin Schwartz", "text": "

OK, but why would this decrease reliance on SNI inspection?

", "time": "2025-07-22T13:30:25Z"}, {"author": "Daniel Gillmor", "text": "

and i have d4, d6, d8, d12, and d20 if you want to get crazy

", "time": "2025-07-22T13:30:36Z"}, {"author": "Jon Varsanik", "text": "

@daniel - lol

", "time": "2025-07-22T13:30:54Z"}, {"author": "David Schinazi", "text": "

MT answered my question: for this you put SCONE on the end of the packet not the front

", "time": "2025-07-22T13:31:45Z"}, {"author": "Jon Varsanik", "text": "

@ben - The expectation is that SCONE is replacing the need for SNI - operators are using SNI to identify video flows and limit them, we are replacing that need with identifying flows based on SCONE compliance instead of inferred content.

", "time": "2025-07-22T13:32:43Z"}, {"author": "Daniel Gillmor", "text": "

if there's no utility, then maybe we shouldn't do it at all!

", "time": "2025-07-22T13:32:49Z"}, {"author": "David Schinazi", "text": "

We established the utility of SCONE a long time ago

", "time": "2025-07-22T13:32:53Z"}, {"author": "Daniel Gillmor", "text": "

that's the shortest possible RFC

", "time": "2025-07-22T13:32:56Z"}, {"author": "David Schinazi", "text": "

What DKG said

", "time": "2025-07-22T13:33:07Z"}, {"author": "Benjamin Schwartz", "text": "

Jon Varsanik said:

\n
\n

@ben - The expectation is that SCONE is replacing the need for SNI - operators are using SNI to identify video flows and limit them, we are replacing that need with identifying flows based on SCONE compliance instead of inferred content.

\n
\n

OK, but this indication doesn't mean \"scone compliant\"? It only means \"scone tolerant\"?

", "time": "2025-07-22T13:33:15Z"}, {"author": "Martin Thomson", "text": "

I think that Sanjay's point here is counteracted by the point about this being tolerant, NOT compliant.

", "time": "2025-07-22T13:33:58Z"}, {"author": "Daniel Gillmor", "text": "

i think this maybe the most recursively phrased show of hands i've ever seen

", "time": "2025-07-22T13:34:44Z"}, {"author": "Harald Alvestrand", "text": "

is the indication going in the quic request, quic response, or both?

", "time": "2025-07-22T13:35:25Z"}, {"author": "Martin Thomson", "text": "

What Sanjay seems to want is to know that the flow will compliant, not tolerant.

", "time": "2025-07-22T13:35:35Z"}, {"author": "David Schinazi", "text": "

I don't buy Matt's argument

", "time": "2025-07-22T13:35:55Z"}, {"author": "Daniel Gillmor", "text": "

I also don't buy it

", "time": "2025-07-22T13:36:03Z"}, {"author": "David Schinazi", "text": "

The box can just look at the first packet in the server-to-client direction

", "time": "2025-07-22T13:36:09Z"}, {"author": "Kyle Nekritz", "text": "

I don't understand how this is helpful, it will easily result in everyone giving the \"indication\"

", "time": "2025-07-22T13:36:12Z"}, {"author": "Alan Frindell", "text": "

Is the show of hands still running?

", "time": "2025-07-22T13:36:14Z"}, {"author": "Jon Varsanik", "text": "

They why not make the guidance in the protocol that the bit indicates \"attempt to comply\" not \"toleate\"

", "time": "2025-07-22T13:36:38Z"}, {"author": "Daniel Gillmor", "text": "

do you support the show of hands about showing support for the SCONE protocol to show support for showing support?

", "time": "2025-07-22T13:36:42Z"}, {"author": "Martin Thomson", "text": "

I have never bought this argument. That leap of faith depends on some assumption about two things: the support for SCONE on the server, and the extent to which the application might comply with advice.

", "time": "2025-07-22T13:37:12Z"}, {"author": "Kyle Nekritz", "text": "

If it's just an attempt to comply, then you have to do DPI anyway

", "time": "2025-07-22T13:37:25Z"}, {"author": "Christian Huitema", "text": "

The more I listen to these arguments, the more I like the preferred address mechanism.

", "time": "2025-07-22T13:37:36Z"}, {"author": "Matt Joras", "text": "

@David Schinazi looking at the packet when it's encrypted is WAY MORE expensive

", "time": "2025-07-22T13:37:44Z"}, {"author": "Martin Thomson", "text": "

Both are unknowable. And even DPI won't help answer those questions.

", "time": "2025-07-22T13:37:44Z"}, {"author": "Matt Joras", "text": "

that's the entire point though

", "time": "2025-07-22T13:37:47Z"}, {"author": "David Schinazi", "text": "

22Y-7N is not rough consensus when there are objections from the floor

", "time": "2025-07-22T13:38:27Z"}, {"author": "Matt Joras", "text": "

There's no a very strong argument to NOT having this in the document, other than \"it might not work as you expect\"

", "time": "2025-07-22T13:38:50Z"}, {"author": "David Schinazi", "text": "

YAGNI is a real argument

", "time": "2025-07-22T13:39:12Z"}, {"author": "Martin Thomson", "text": "

It's stronger than that: it's \"it will not work as you expect\"

", "time": "2025-07-22T13:39:18Z"}, {"author": "Daniel Gillmor", "text": "

the argument against it is that we want to generally discourage putting cleartext on the outside of the encrypted envelope.

", "time": "2025-07-22T13:39:22Z"}, {"author": "Matt Joras", "text": "

SCONE packets are in cleartext though anyway?

", "time": "2025-07-22T13:39:41Z"}, {"author": "Matt Joras", "text": "

there is not net new information here

", "time": "2025-07-22T13:39:47Z"}, {"author": "Daniel Gillmor", "text": "

deviations from that general principle need strong justification

", "time": "2025-07-22T13:39:50Z"}, {"author": "Matt Joras", "text": "

except for the case where SCONE is never used but is negotiated

", "time": "2025-07-22T13:39:59Z"}, {"author": "Martin Thomson", "text": "

dkg++

", "time": "2025-07-22T13:40:09Z"}, {"author": "David Schinazi", "text": "

Tommy is right. The box is trying to find the video flows. It's not looking for client implementations that happen to understand SCONE headers

", "time": "2025-07-22T13:40:35Z"}, {"author": "Benjamin Schwartz", "text": "

Does the indication mean \"I promise that I will comply with SCONE if I am a video flow\"?

", "time": "2025-07-22T13:40:36Z"}, {"author": "Alan Frindell", "text": "

@ben - no

", "time": "2025-07-22T13:40:45Z"}, {"author": "Alan Frindell", "text": "

it just means you can receive the signal

", "time": "2025-07-22T13:41:01Z"}, {"author": "Daniel Gillmor", "text": "

ben, you keep asking that question \u263a do you not like the answer you're getting?

", "time": "2025-07-22T13:41:02Z"}, {"author": "David Schinazi", "text": "

If it means \"I won't barf on SCONE\" then Chrome will just send it on all QUIC

", "time": "2025-07-22T13:41:03Z"}, {"author": "Christian Huitema", "text": "

DKG is right.

", "time": "2025-07-22T13:41:08Z"}, {"author": "Christian Huitema", "text": "

It is just a boondoggle.

", "time": "2025-07-22T13:41:27Z"}, {"author": "Daniel Gillmor", "text": "

\"maybe not look at the SNI\"?

", "time": "2025-07-22T13:41:38Z"}, {"author": "Alan Frindell", "text": "

if we include the signal, it will shorten the transition when we need it. How ironic

", "time": "2025-07-22T13:42:17Z"}, {"author": "Jon Varsanik", "text": "

As a CAP - it is in my interest to comply with the SCONE guidance, as opposed to throttling / shaping. My hope is that SCONE compliance means reduced application of throttling / shaping (as long as I stay in compliance with overall throughput guidance).

", "time": "2025-07-22T13:42:20Z"}, {"author": "Martin Thomson", "text": "

Can anyone tell me what the DPI looks for?

", "time": "2025-07-22T13:42:23Z"}, {"author": "David Schinazi", "text": "

But for \"don't look at SNI\" to work, this signal needs to answer the questions that the box is looking at SNI for. And that's not SCONE support, it's video

", "time": "2025-07-22T13:42:24Z"}, {"author": "Martin Thomson", "text": "

It's SNI, right?

", "time": "2025-07-22T13:42:29Z"}, {"author": "Matt Joras", "text": "

@Martin Thomson it is trial decryption and looking at SNI, largely

", "time": "2025-07-22T13:42:40Z"}, {"author": "Christian Huitema", "text": "

But we can force the network to not look at the SNI. Suffice to use the \"preferred address\" option, so the 4-tuple of the SNI-carrying packet is not the same as the 4-tuple of the video carrying packets.

", "time": "2025-07-22T13:42:54Z"}, {"author": "David Schinazi", "text": "

As someone who regularly breaks DPI, yes they look at SNI and compare it against a list of video providers

", "time": "2025-07-22T13:42:58Z"}, {"author": "Martin Thomson", "text": "

But we are not getting a guarantee that this signal is an effective replacement for DPI for SNI.

", "time": "2025-07-22T13:43:01Z"}, {"author": "Matt Joras", "text": "

It is a compromise not a guarantee

", "time": "2025-07-22T13:43:15Z"}, {"author": "Matt Joras", "text": "

and it is a compromise they have stated a willingness to use

", "time": "2025-07-22T13:43:22Z"}, {"author": "Martin Thomson", "text": "

Compromise has multiple meanings.

", "time": "2025-07-22T13:43:26Z"}, {"author": "Alan Frindell", "text": "

Using SNI to determine shaping is really bad, because it means we can't multiplex video and non-video, which further hurts QoE

", "time": "2025-07-22T13:43:27Z"}, {"author": "Benjamin Schwartz", "text": "

Is this signal at all correlated with video SNI?

", "time": "2025-07-22T13:43:27Z"}, {"author": "Matt Joras", "text": "

It is not a 1:1 replacement for DPI

", "time": "2025-07-22T13:43:34Z"}, {"author": "Daniel Gillmor", "text": "

Martin, ha ha

", "time": "2025-07-22T13:43:36Z"}, {"author": "Rodrigo Broilo", "text": "

DPI can look for SNI, also can do DNS snooping and use heuristics to say is video or not... seems that SNI is the cheaper option!

", "time": "2025-07-22T13:43:56Z"}, {"author": "Jon Varsanik", "text": "

@Matt --> \"willingness to use\" is a good indication which is closer in my mind to \"expect to comply\" vs. \"can tolerate\"

", "time": "2025-07-22T13:44:10Z"}, {"author": "Christian Huitema", "text": "

The reality is that applications do not want to be shaped, and thus are guaranteed to use evasive tactics.

", "time": "2025-07-22T13:45:04Z"}, {"author": "Daniel Gillmor", "text": "

right, the apps are going to think that sending this first packet means \"don't shape me, bro\"

", "time": "2025-07-22T13:46:45Z"}, {"author": "Benjamin Schwartz", "text": "

Tagging SCONE flows from the first packet seems like a pretty sensible idea. If the client wants SCONE, surely it wants SCONE ASAP? I just don't understand the motivation that's been described.

", "time": "2025-07-22T13:47:15Z"}, {"author": "Matt Joras", "text": "

The motivation is purely a network element resource cost motivation.

", "time": "2025-07-22T13:47:43Z"}, {"author": "Daniel Gillmor", "text": "

does the client want SCONE? or do they want to not hit a shaper?

", "time": "2025-07-22T13:47:44Z"}, {"author": "Jon Varsanik", "text": "

But the goal of SCONE is to be a \"non-evasive\" way to avoid shaping, but achieve the goal of reducing network tonnage.

", "time": "2025-07-22T13:47:51Z"}, {"author": "Brian Trammell", "text": "

dkg: they want to configure their own internal shaper to avoid the network shaper

", "time": "2025-07-22T13:48:18Z"}, {"author": "Daniel Gillmor", "text": "

sure. but that's because they don't want to be shaped

", "time": "2025-07-22T13:48:32Z"}, {"author": "Daniel Gillmor", "text": "

but all traffic might be throttled, right?

", "time": "2025-07-22T13:49:15Z"}, {"author": "Brian Trammell", "text": "

because they believe their shaper is better for their traffic (usually true), and they want to configure it to get the maximum throughput not subject to external shaping

", "time": "2025-07-22T13:49:15Z"}, {"author": "Martin Thomson", "text": "

The nature of the deal is that you implement SCONE, respect the limit, and get looser enforcement (and therefore better performance).

", "time": "2025-07-22T13:49:18Z"}, {"author": "Jon Varsanik", "text": "

We shared data in previous IETF meetigs showing that we can achieve much better QoE at the same throughput by reducing bitrates at the application level, and removing network shaping.

", "time": "2025-07-22T13:49:47Z"}, {"author": "Harald Alvestrand", "text": "

client to server indication of scone support could be taken to mean \"if I get the scone signal, I may do something with it\". Server to client indication of scone support could be taken to mean \"I will send scone packets on this 4-tuple\". The meaning of the two are not the same.
\nIs the server-to-client indication the only one that should go on the outside of the envelope?

", "time": "2025-07-22T13:51:19Z"}, {"author": "Martin Thomson", "text": "

In the presence of SCONE, the network could swap shaping for monitoring. (And swap monitoring for shaping if the monitoring fails.)

", "time": "2025-07-22T13:51:41Z"}, {"author": "Matt Joras", "text": "

I don't think David saying \"what the box cares about\" is particularly compelling when talking to the people that make \"the box\" saying it would be useful

", "time": "2025-07-22T13:53:22Z"}, {"author": "Alan Frindell", "text": "

i can download an ABR video on any connection, so why wouldn't I send the scone signal all the time.

", "time": "2025-07-22T13:54:01Z"}, {"author": "Kazuho Oku", "text": "

I do not get how we could have a better form of \"indication\" when endpoints can cheat

", "time": "2025-07-22T13:54:46Z"}, {"author": "Daniel Gillmor", "text": "

the flip side of what Schinazi just said is \"if we want to indicate something concrete about the traffic itself with this indicator\u2026\" then we're basically saying \"we want to leak distinguishing metadata about this flow to the network\". that's something we should avoid doing in general, without clear limits and strong arguments for benefit.

", "time": "2025-07-22T13:54:47Z"}, {"author": "Martin Thomson", "text": "

Making this more useful would make it more useful... for privacy privacy violations

", "time": "2025-07-22T13:55:18Z"}, {"author": "Matt Joras", "text": "

We are explicitly encouraging all QUIC flows to do this. And also, SCONE \"information\" is explicitly clear on the wire, unless we _don't use SCONE_ and use ECH

", "time": "2025-07-22T13:55:27Z"}, {"author": "Daniel Gillmor", "text": "

Martin +1

", "time": "2025-07-22T13:55:33Z"}, {"author": "David Schinazi", "text": "

Agree with DKG, even beyond getting this to mean something useful, we shouldn't leak it unless we think it's a good idea

", "time": "2025-07-22T13:56:11Z"}, {"author": "Martin Thomson", "text": "

If we have a signal, it should not be reliable.

", "time": "2025-07-22T13:56:17Z"}, {"author": "Alan Frindell", "text": "

I view it as the gunman is telling us they're about to release a hostage (turn off the shaper) in exchange for this signal - even if the signal doesn't leak anything because it's ubiquitous. I think we should take the deal.

", "time": "2025-07-22T13:57:35Z"}, {"author": "Matt Joras", "text": "

Can you eexplain what is beign leaked @David Schinazi @Daniel Gillmor ?

", "time": "2025-07-22T13:57:48Z"}, {"author": "Daniel Gillmor", "text": "

i don't even know what is being leaked at this point

", "time": "2025-07-22T13:58:43Z"}, {"author": "Daniel Gillmor", "text": "

i've heard several different semantic interpretations

", "time": "2025-07-22T13:58:53Z"}, {"author": "Daniel Gillmor", "text": "

and if it's applied to every QUIC connection, then why bother?

", "time": "2025-07-22T13:59:04Z"}, {"author": "Matt Joras", "text": "

The ONLY case where there is net new information with an indication is:

\n
    \n
  1. SCONE is negotiated with ECH
    2. \n
  2. NO SCONE packet is ever sent on the connection
    3. \n
", "time": "2025-07-22T13:59:12Z"}, {"author": "Alan Frindell", "text": "
\n

and if it's applied to every QUIC connection, then why bother?

\n
\n

Because they said they would turn off the shaper, which is a win for the users.

", "time": "2025-07-22T13:59:47Z"}, {"author": "Harald Alvestrand", "text": "

if the scone indication is set on all traffic, the only possible meaning is \"I will obey SCONE restrictions if you send them to me, and I'll send SCONE probes to collect those signals\":

", "time": "2025-07-22T13:59:51Z"}, {"author": "Daniel Gillmor", "text": "

i disagree with the claim that there is anything approaching a rough consensus to do something.

", "time": "2025-07-22T14:00:08Z"}, {"author": "David Schinazi", "text": "

Yeah that was not consensus

", "time": "2025-07-22T14:01:05Z"}, {"author": "Daniel Gillmor", "text": "

@Harald, this is why Ben keeps asking the question of \"what does this mean?\"

", "time": "2025-07-22T14:01:07Z"}, {"author": "Daniel Gillmor", "text": "

Alan, i don't believe that anyone will turn off any shapers

", "time": "2025-07-22T14:01:29Z"}, {"author": "Alan Frindell", "text": "

The people with the shapers said they would. I guess I'm willing to trust them but I understand why you are not.

", "time": "2025-07-22T14:01:57Z"}, {"author": "Daniel Gillmor", "text": "

i don't think they can. they have to keep the threat of enforcement if this is offered as guidance

", "time": "2025-07-22T14:02:29Z"}, {"author": "Alan Frindell", "text": "

sure, there's still monitoring and eventual enforcement if the app is not following advice

", "time": "2025-07-22T14:03:00Z"}, {"author": "Daniel Gillmor", "text": "

so how is that \"turning off the shaper\"?

", "time": "2025-07-22T14:03:16Z"}, {"author": "Alan Frindell", "text": "

As long as we self-shape, then we don't hit their shaper

", "time": "2025-07-22T14:03:31Z"}, {"author": "Benjamin Schwartz", "text": "

@Daniel Gillmor \"off\" == \"not shaping right now\"

", "time": "2025-07-22T14:03:35Z"}, {"author": "Mike Blanche", "text": "

i can see a world where if enough traffic adheres to SCONE advice then it's no longer worth deploying shapers for the remainder

", "time": "2025-07-22T14:03:41Z"}, {"author": "Matt Joras", "text": "

+1 Mike

", "time": "2025-07-22T14:03:47Z"}, {"author": "Kazuho Oku", "text": "

Clients send Indications in hope that they will be policed accordingly to the SCONE specification rather than by SNI. And for network elements, starting with applying SCONE-conformant policy only for flows having Indications is easier than switching on day one to SCONE-conformant policy for entire traffic.

", "time": "2025-07-22T14:03:53Z"}, {"author": "Daniel Gillmor", "text": "

Mike, at that point, clients will just cheat, right?

", "time": "2025-07-22T14:04:08Z"}, {"author": "Alan Frindell", "text": "

For the Meta and YT and TikToks of the world, they notice when we cheat pretty quickly

", "time": "2025-07-22T14:04:42Z"}, {"author": "Matt Joras", "text": "

Not at large scale, most likely.

", "time": "2025-07-22T14:04:44Z"}, {"author": "Mike Blanche", "text": "

@daniel i guess an equilibrium will establish itself - conformance falls below a certain level, shapers start getting deployed again

", "time": "2025-07-22T14:04:46Z"}, {"author": "David Schinazi", "text": "

What does the shaper do if the client sends the indication but the server doesn't support SCONE?

", "time": "2025-07-22T14:05:22Z"}, {"author": "Alan Frindell", "text": "

This is why our ECH deployments are limited, and why we can't blend video and non-video traffic

", "time": "2025-07-22T14:05:23Z"}, {"author": "Matt Joras", "text": "

And the repercussions for cheating \"at scale\" can be quite bad for the business potentially

", "time": "2025-07-22T14:05:28Z"}, {"author": "Alan Frindell", "text": "

if the client doesn't adhere to the advice - there's a credible threat of network violence

", "time": "2025-07-22T14:06:03Z"}, {"author": "Jon Varsanik", "text": "

+1 to Martin! Should this time window (for compliance) also be the time window recommended for frequency of updating (or confirming) the guidance!

", "time": "2025-07-22T14:06:08Z"}, {"author": "Alan Frindell", "text": "

that includes cases where the server doesn't send scone packets for carrying advice

", "time": "2025-07-22T14:06:40Z"}, {"author": "Sanjay Mishra", "text": "

Network has shapers today and don't need SCONE. But, the current methods don't make content publishers happy because of increased \"tonnage\", so the question is, does SCONE provides an alternative to the network and the network operators are looking to see how SCONE can be deployed in the network and then how might SCONE work \"better\" or differently in the network so current shapers can be replaced over time.

", "time": "2025-07-22T14:08:41Z"}, {"author": "Christian Huitema", "text": "

Nyquist. If the signal is valid for time T, the probe should be at T/2

", "time": "2025-07-22T14:08:52Z"}, {"author": "Chris Box", "text": "

Whatever we do here should allow for the dynamic use case described in the introduction e.g. \"reduced capacity due to overuse, equipment faults, or other transient issues; conversely, networks might choose to signal increased availability of capacity.\"

", "time": "2025-07-22T14:09:19Z"}, {"author": "Christian Huitema", "text": "

Reduced capcity is really for ECN, not for SCONE

", "time": "2025-07-22T14:09:51Z"}, {"author": "Chris Box", "text": "

The previous sentence is \"Network elements in access networks could provide information to endpoints that can help account for changes in network capacity that are not suited to congestion control feedback.\"

", "time": "2025-07-22T14:10:42Z"}, {"author": "Matt Joras", "text": "

yeah not all network capacity changes have a 1:1 mapping with traditional congestion signals

", "time": "2025-07-22T14:11:28Z"}, {"author": "Christian Huitema", "text": "

Yes, they say that. Doesn't change the fact that short term changes are best served with short term signals like CN.

", "time": "2025-07-22T14:12:02Z"}, {"author": "Christian Huitema", "text": "

(ECN)

", "time": "2025-07-22T14:12:22Z"}, {"author": "Matt Joras", "text": "

Agreed, but sometimes there are longer term predictable ones that make sense. For example \"there's going to be a stadium filled with 50k people and I only have X RANs\"

", "time": "2025-07-22T14:12:37Z"}, {"author": "Matt Joras", "text": "

\"Wouldn't it be great if all the applications knew at the start of the flow to not go nuts\"

", "time": "2025-07-22T14:12:59Z"}, {"author": "Christian Huitema", "text": "

Then the network starts signalling that 1 minute in advance.

", "time": "2025-07-22T14:13:05Z"}, {"author": "Matt Joras", "text": "

signaling congestion does not have a clean mapping to application behavior whereas throughput advice is closer

", "time": "2025-07-22T14:13:51Z"}, {"author": "Matt Joras", "text": "

it is more immediately actionable especially for an ABR video player and there's no algorithm or distributed algorithm CCA involved

", "time": "2025-07-22T14:14:18Z"}, {"author": "Matt Joras", "text": "

they are complementary

", "time": "2025-07-22T14:14:22Z"}, {"author": "Christian Huitema", "text": "

\"the fiber broke\" does not have a clear mapping to apps either.

", "time": "2025-07-22T14:14:23Z"}, {"author": "Harald Alvestrand", "text": "

Throughput advice to a VC application is going to have a VERY different result from throughput advice on a VOD application....

", "time": "2025-07-22T14:14:46Z"}, {"author": "Matt Joras", "text": "

If my capacity is halved as an operator, and I know I can usually provide an experiences that have throughput-ish X, then I have a way to tell the app \"plz use X/2 plzzzzzzz\"

", "time": "2025-07-22T14:15:20Z"}, {"author": "Benjamin Schwartz", "text": "

End-to-end congestion control is awesome, but it's never going to solve the problem of blowing out my month's data plan in 15 minutes because the network is _too fast_.

", "time": "2025-07-22T14:17:24Z"}, {"author": "Harald Alvestrand", "text": "

If I'm VC and am told \"2 Mbits averaged over a 120 sec window, or we'll police you\", I'll make very sure to keep my rate under 2 Mbits, so that I don't run out of capacity at the end of the window.

", "time": "2025-07-22T14:18:31Z"}, {"author": "Harald Alvestrand", "text": "

Not CBR, but spreading the traffic over the whole window.

", "time": "2025-07-22T14:18:57Z"}, {"author": "Chris Box", "text": "

Indeed, because you don't know how complex the video will become towards the end of the window.

", "time": "2025-07-22T14:19:15Z"}, {"author": "Daniel Gillmor", "text": "

that's true for sending, but you can't guarantee it for receiving; you can only signal your peer about how you'll hope they encode.

", "time": "2025-07-22T14:19:48Z"}, {"author": "Daniel Gillmor", "text": "

(assuming peer-to-peer VC)

", "time": "2025-07-22T14:20:05Z"}, {"author": "Vinicius Fortuna", "text": "

I'm my view it's not one rate, or a peak and average rate, but a list of rates. They are all data/time, with different time windows. Perhaps the network should communicate a list of rates.

", "time": "2025-07-22T14:20:38Z"}, {"author": "Harald Alvestrand", "text": "

When doing VC, I'm (conceptually) doing the worrying on the sender side. (which means that the receiver needs to tell me what SCONE signals it has received)

", "time": "2025-07-22T14:20:54Z"}, {"author": "David Schinazi", "text": "

How would the recipient of this ACK react to receiving an ACK or not?

", "time": "2025-07-22T14:20:58Z"}, {"author": "Harald Alvestrand", "text": "

what ACK?

", "time": "2025-07-22T14:21:17Z"}, {"author": "Brian Trammell", "text": "

SCACK

", "time": "2025-07-22T14:22:09Z"}, {"author": "Matt Joras", "text": "

@David Schinazi that's basically the reason to close it. there's no guarantees that can be made or information that's conveyed really by the ACK

", "time": "2025-07-22T14:22:16Z"}, {"author": "David Schinazi", "text": "

@Harald The issue #7 that we were just discussing

", "time": "2025-07-22T14:22:24Z"}, {"author": "David Schinazi", "text": "

@Matt. Perfect, then I agree :)

", "time": "2025-07-22T14:22:32Z"}, {"author": "Brian Trammell", "text": "

\"endpoint received advice packet\"

", "time": "2025-07-22T14:22:32Z"}, {"author": "Daniel Gillmor", "text": "

Harald -- on peer-to-peer VC, both sides may have received indicators; if those indicators have different values, how do they adjust? are they bidirectional signals?

", "time": "2025-07-22T14:23:50Z"}, {"author": "Christian Huitema", "text": "

One way signals. That's in the draft.

", "time": "2025-07-22T14:24:27Z"}, {"author": "Harald Alvestrand", "text": "

Daniel - on peer-to-peer VC, the reciever is already telling the sender what it would like to receive, based on the resolution of the screen, the heat of his CPU (decode capacity) and more signals that I've now forgotten. Received SCONE would be just another thing to include in the \"view request\".

", "time": "2025-07-22T14:26:06Z"}, {"author": "Harald Alvestrand", "text": "

and yes, this is commonly application-specific messaging.

", "time": "2025-07-22T14:28:41Z"}, {"author": "Martin Thomson", "text": "

8 oct might be awkward for me, later would be good

", "time": "2025-07-22T14:32:37Z"}]