checking my mic
", "time": "2025-05-21T21:04:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "Hello! Do we have an agenda for today/tonight?
", "time": "2025-05-21T21:04:24Z"}, {"author": "Mirja K\u00fchlewind", "text": "no, was hoping for a short meeting ;-)
", "time": "2025-05-21T21:05:11Z"}, {"author": "Michael Richardson", "text": "could the screen sharer please CTRL+ a few times, or better make your window narrow enough so it's not 2/3
", "time": "2025-05-21T21:13:41Z"}, {"author": "Michael Richardson", "text": "blank.
", "time": "2025-05-21T21:13:44Z"}, {"author": "Christian Huitema", "text": "doesn't the charter say \"allow an application to receive notifications
\ncontaining throughput advice\"? Iy does not say \"communicate application profiles to the network\"!
https://github.com/ietf-wg-scone/scone/issues/5
", "time": "2025-05-21T21:14:19Z"}, {"author": "Kazuho Oku", "text": "nice summary!
", "time": "2025-05-21T21:15:10Z"}, {"author": "Martin Thomson", "text": "What Christian said. I would not support the view that this would be conditional. On the contrary, I would rather have SCONE possible on every flow, which eventually be a zero information signal to the network.
", "time": "2025-05-21T21:15:20Z"}, {"author": "Alan Frindell", "text": "I was also told there would be MUFFIN packets.
", "time": "2025-05-21T21:15:33Z"}, {"author": "Martin Thomson", "text": "On every connection, Ian.
", "time": "2025-05-21T21:16:12Z"}, {"author": "Christian Huitema", "text": "The goal is not to enable more fingerprinting of applications!
", "time": "2025-05-21T21:16:48Z"}, {"author": "Martin Thomson", "text": "We'd need a JS API hook for it, if the server needed to know. Then you can send it up.
", "time": "2025-05-21T21:17:05Z"}, {"author": "Martin Thomson", "text": "That's the obvious thing to do for a browser.
", "time": "2025-05-21T21:17:17Z"}, {"author": "Ian Swett", "text": "SGTM, that makes sense.
", "time": "2025-05-21T21:22:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "The indication would only say that this traffic likely would benefit from receiving the scone signal and that's what you leaking anyway by just using scone. It doesn't tell you if this is video traffic and that doesn't matter. It just tells what the endpoint thinks might be useful for this traffic.
", "time": "2025-05-21T21:23:28Z"}, {"author": "Martin Thomson", "text": "That is also my position: we don't want to enable more fingerprinting.
", "time": "2025-05-21T21:23:30Z"}, {"author": "Martin Thomson", "text": "Mirja: that's not true if every flow has SCONE enabled.
", "time": "2025-05-21T21:23:55Z"}, {"author": "Matt Joras", "text": "I have made this point on the thread, but allowing a realistic way to remove this particular reliance on DPI is an aopportunity to _reduce the fingerprinting surface_
", "time": "2025-05-21T21:24:07Z"}, {"author": "Martin Duke", "text": "@MT why couldn't a browser negotiate SCONE with the server and then only start appending SCONE when it knows it's got video, in principle?
", "time": "2025-05-21T21:24:31Z"}, {"author": "Matt Joras", "text": "This is _very_ similar to the public name tradeoff in for example ECH
", "time": "2025-05-21T21:24:32Z"}, {"author": "Martin Thomson", "text": "Then the network can signal throughput advice, but there is no guarantee is followed. There's some leakage from flows that do follow advice, but that's the cooperative.
", "time": "2025-05-21T21:24:36Z"}, {"author": "Mirja K\u00fchlewind", "text": "even if every client will request scone, I wouldn't expect that alll traffic will be scone enabled at the end.
", "time": "2025-05-21T21:24:42Z"}, {"author": "Ian Swett", "text": "I think I want different treatment for VC than VoD, but maybe that's out of scope
", "time": "2025-05-21T21:24:45Z"}, {"author": "Alan Frindell", "text": "Isn't it trivial to identify a flow as video just based on the shape of the traffic on the wire?
", "time": "2025-05-21T21:25:00Z"}, {"author": "Martin Thomson", "text": "Martin D: we could only do that if we split the connection pool (again). I'd really like to avoid having to do that as it is a lot of extra complexity and work.
", "time": "2025-05-21T21:25:29Z"}, {"author": "Martin Thomson", "text": "Alan: sure, but then flows that respect any advice that aren't video will also look like video
", "time": "2025-05-21T21:26:34Z"}, {"author": "Alan Frindell", "text": "Do we have another example of adaptive bitrate traffic that might scone?
", "time": "2025-05-21T21:27:47Z"}, {"author": "Martin Thomson", "text": "VC and VOD are both options here. Software updates might also benefit.
", "time": "2025-05-21T21:28:13Z"}, {"author": "Kazuho Oku", "text": "update downloads? (just saying)
", "time": "2025-05-21T21:28:18Z"}, {"author": "Dan Druta", "text": "What\u2019s wrong with \u201cI\u2019m adaptive video\u201d signal? We had packet markings from the beginning of the internet. They get bleached because are used for QoS so we lost that ability
", "time": "2025-05-21T21:28:56Z"}, {"author": "Alan Frindell", "text": "Is there a \"low res\" version of a software update? Or we're thinking that the sender will send it more slowly
", "time": "2025-05-21T21:29:02Z"}, {"author": "Martin Thomson", "text": "Dan: the DSCP/QoS question isn't really at issue here, at least for me. The problem is that an end state for this doesn't benefit from an indication; therefore, the signal only provides value in a transitionary phase, where support is rolling out. During that phase, the indication means something more than just a QoS signal, because it carries other information. Like whether you have the latest Facebook app, or whatever app that was just updated.
", "time": "2025-05-21T21:31:34Z"}, {"author": "Martin Thomson", "text": "Alan: for software updates, I imagine that it would be that the sender paces themselves.
", "time": "2025-05-21T21:32:01Z"}, {"author": "Mirja K\u00fchlewind", "text": "even if you have an early indication, you still need to monitor the rate in case you want to enforce the limit through throttling because there is no guarantee that the signal will be applies. That does not depend on the early indication at all.
", "time": "2025-05-21T21:34:39Z"}, {"author": "Martin Thomson", "text": "I'm not sure that this argument Matt uses here is correct. It is only correct IF the SCONE packet is sent. Which will not happen on many flows.
", "time": "2025-05-21T21:36:23Z"}, {"author": "Martin Thomson", "text": "So the information release is different than what can be gained by observing SCONE packets.
", "time": "2025-05-21T21:37:17Z"}, {"author": "Ian Swett", "text": "So we could send SCONE-video or SCONE-web as the SNI?
", "time": "2025-05-21T21:38:14Z"}, {"author": "Ian Swett", "text": "(when using ECH)
", "time": "2025-05-21T21:38:50Z"}, {"author": "Martin Thomson", "text": "We could, but I wouldn't.
", "time": "2025-05-21T21:39:05Z"}, {"author": "Matt Joras", "text": "Martin: without ECH, the support for SCONE is visible to a network element, via DPI and CH parsing. The information release is the same.
\nWith ECH, a flow that _never_ uses SCONE indeed does not have that information available, but that's not a super compelling use case
", "time": "2025-05-21T21:40:30Z"}, {"author": "Martin Thomson", "text": "It is to me :)
", "time": "2025-05-21T21:40:53Z"}, {"author": "Martin Thomson", "text": "That's most web traffic, ideally.
", "time": "2025-05-21T21:41:08Z"}, {"author": "Matt Joras", "text": "Most web traffic is video
", "time": "2025-05-21T21:41:32Z"}, {"author": "Martin Thomson", "text": "I'm not talking by volume, but by destination/connection/whatever
", "time": "2025-05-21T21:41:50Z"}, {"author": "Ian Swett", "text": "By bytes, not flows
", "time": "2025-05-21T21:41:52Z"}, {"author": "Michael Richardson", "text": "all of this just screams for a (better) host to network API. Can we repurpose RSVP from the end-point (receiver) to the network, with the notion that ISPs a few hops away will just drop it?
", "time": "2025-05-21T21:41:56Z"}, {"author": "Martin Thomson", "text": "I'm most interested in this vision Marcus describes here. Where the network doesn't discriminate based on type of traffic, but on its characteristics.
", "time": "2025-05-21T21:44:34Z"}, {"author": "Matt Joras", "text": "Martin: I still do not see how this is a compelling differentiator in fingerprinting. We are apparently okay with the protocol having something that's fingerprintable for the majority of bytes on the Internet.
\nAnd a client is still wholly capable of just _not_ sending the indication if it does not want to.
", "time": "2025-05-21T21:44:40Z"}, {"author": "Christian Huitema", "text": "What is in charter is a way for operators to expose their traffic policy, not an input to chosing that policy. If the network does DPI, it will continue doing so, but if it sees a scone packet, it will provide athroughput advice consistent with the policy that it has already chosen.
", "time": "2025-05-21T21:46:53Z"}, {"author": "Michael Richardson", "text": "what Christian said.
", "time": "2025-05-21T21:47:19Z"}, {"author": "Kazuho Oku", "text": "Sanjay: Yeah SCONE is about eliminating the need to use CC (packet drops / ECNs) for rate limiting.
", "time": "2025-05-21T21:47:45Z"}, {"author": "Martin Thomson", "text": "Matt: that makes the fingerprint carry MORE information, not less
", "time": "2025-05-21T21:48:32Z"}, {"author": "Christian Huitema", "text": "The purpose of the indication is to apply policy based on an indication before it provides throughput advice. I think that's the most compelling reason to not do an indication.
", "time": "2025-05-21T21:49:48Z"}, {"author": "Matt Joras", "text": "Martin: for non-ECH, what net new information is available to the network element capable of parsing client hellos when using an indication?
", "time": "2025-05-21T21:50:10Z"}, {"author": "Christian Huitema", "text": "The indication is a way to drive adoption for the wrong reasons!
", "time": "2025-05-21T21:52:04Z"}, {"author": "Kazuho Oku", "text": "what Christian says
", "time": "2025-05-21T21:52:27Z"}, {"author": "Martin Thomson", "text": "Matt: at least during transition, whether the flow is from an app that has been updated to support SCONE, or not
", "time": "2025-05-21T21:53:08Z"}, {"author": "Matt Joras", "text": "Martin: That information is available in the transport parameters extension of the CH in the QUIC initial
", "time": "2025-05-21T21:53:42Z"}, {"author": "Martin Thomson", "text": "At least in theory, Firefox and Chrome could appear identical to the Facebook app in connecting to an arbitrary server.
", "time": "2025-05-21T21:53:47Z"}, {"author": "Martin Duke", "text": "If a bunch of endpoints just decide that they will always advertise SCONE, this is neither a worthwhile fingerprint nor an incentive to get rid of DPI
", "time": "2025-05-21T21:56:24Z"}, {"author": "Martin Thomson", "text": "I don't consider non-ECH/ECH to be something we should base decisions on.
", "time": "2025-05-21T21:56:53Z"}, {"author": "Martin Thomson", "text": "But I know that people disagree.
", "time": "2025-05-21T21:56:59Z"}, {"author": "Michael Richardson", "text": "video today. Immersive VR next year. Multiprocessing upgrades to my brain in a decade... don't fight last year's war.
", "time": "2025-05-21T21:57:04Z"}, {"author": "Christian Huitema", "text": "As in, moving information outside of the encryption envelope!
", "time": "2025-05-21T21:57:05Z"}, {"author": "Matt Joras", "text": "Kazuho: it's okay I've clicked the wrong button every time :)
", "time": "2025-05-21T21:57:14Z"}, {"author": "Martin Thomson", "text": "What Martin Duke said.
", "time": "2025-05-21T21:57:25Z"}, {"author": "Matt Joras", "text": "Christian: an encrypted envelope that is not private...
", "time": "2025-05-21T21:57:35Z"}, {"author": "Christian Huitema", "text": "With ECH it is.
", "time": "2025-05-21T21:57:46Z"}, {"author": "Matt Joras", "text": "And ECH deployment is _hindered by these very DPI policies_
", "time": "2025-05-21T21:58:04Z"}, {"author": "Matt Joras", "text": "With ECH, without the indicating, we have to put SNI in the outer CH
", "time": "2025-05-21T21:58:53Z"}, {"author": "Christian Huitema", "text": "And you can just as well put the same SNI in thouter CH of clients that are not doing video...
", "time": "2025-05-21T21:59:50Z"}, {"author": "Kazuho Oku", "text": "Personally, I would hope all web browsers start attaching SCONE to all the traffic they generate, before network elements start acting upon it.
", "time": "2025-05-21T22:01:14Z"}, {"author": "Martin Thomson", "text": "My plan, if we implement, would be to make SCONE available on every QUIC flow Firefox initiates.
", "time": "2025-05-21T22:01:25Z"}, {"author": "Martin Thomson", "text": "Even without a Web API.
", "time": "2025-05-21T22:01:40Z"}, {"author": "Christian Huitema", "text": "Same here -- but of course the deployment scope of picoquic is somewhat smaller than Firefox.
", "time": "2025-05-21T22:02:03Z"}, {"author": "Dan Druta", "text": "We are making assumptions on what browsers can do without discussing the Web API requirements. The API could have the JS app indicate they initiate video
", "time": "2025-05-21T22:02:47Z"}, {"author": "Christian Huitema", "text": "or bittorrent...
", "time": "2025-05-21T22:03:02Z"}, {"author": "Martin Thomson", "text": "Dan: I can tell you that that is not something we could act on.
", "time": "2025-05-21T22:03:06Z"}, {"author": "Martin Thomson", "text": "We cannot build that API, because to implement it, we would have to completely change connection management.
", "time": "2025-05-21T22:03:44Z"}, {"author": "Martin Thomson", "text": "With some exceptions (which are terrible and we regret every one of them), browsers create connections without knowing how they might be used.
", "time": "2025-05-21T22:04:36Z"}, {"author": "Martin Duke", "text": "@brian your keyboard is load
", "time": "2025-05-21T22:08:17Z"}, {"author": "Martin Duke", "text": "loud
", "time": "2025-05-21T22:08:19Z"}, {"author": "Gorry Fairhurst", "text": "+1 to Mirja
", "time": "2025-05-21T22:11:19Z"}, {"author": "Christian Huitema", "text": "at mirja, I agree. if there is no throttling policy, scone is still useful.
", "time": "2025-05-21T22:11:25Z"}, {"author": "Brian Trammell", "text": "@martin yeah i expect to hear the same thing from my family about charing late night interims. :) puted.
", "time": "2025-05-21T22:11:32Z"}, {"author": "Brian Trammell", "text": "muted.
", "time": "2025-05-21T22:11:34Z"}, {"author": "Martin Thomson", "text": "Again, I disagree with Mirja: So the network says you can get 10Tbps. And that is true for the element that is saying that, but that element cannot speak for other elements on the same path, which might not have that much capacity available.
", "time": "2025-05-21T22:11:37Z"}, {"author": "Mirja K\u00fchlewind", "text": "the network tells you you should not use _more_ than 10 Tbps
", "time": "2025-05-21T22:12:31Z"}, {"author": "Mirja K\u00fchlewind", "text": "it does not guarantee you that rate
", "time": "2025-05-21T22:12:37Z"}, {"author": "Mirja K\u00fchlewind", "text": "does not
", "time": "2025-05-21T22:12:41Z"}, {"author": "Martin Thomson", "text": "right, which is approximately useless, until your CC gets close to that
", "time": "2025-05-21T22:12:51Z"}, {"author": "Wesley Eddy", "text": "It's useful, because it tells you not to select ABR video options above that, without needing to use CC or other inference.
", "time": "2025-05-21T22:13:33Z"}, {"author": "Mirja K\u00fchlewind", "text": "I think sending a rate limit of 10 Tbps is useless, yes.
", "time": "2025-05-21T22:13:46Z"}, {"author": "Martin Duke", "text": "perfect time for west coast!
", "time": "2025-05-21T22:15:36Z"}, {"author": "Mirja K\u00fchlewind", "text": "Thanks! Bye!
", "time": "2025-05-21T22:15:48Z"}, {"author": "Gorry Fairhurst", "text": "bye
", "time": "2025-05-21T22:15:54Z"}]