First post! Ha :grinning:
", "time": "2024-12-12T16:03:10Z"}, {"author": "Brian Trammell", "text": "hi Jason!
", "time": "2024-12-12T16:04:39Z"}, {"author": "Ted Hardie", "text": "Chairs, do we have a note-taker?
", "time": "2024-12-12T16:04:58Z"}, {"author": "Ted Hardie", "text": "Raising a problem, but I can help out if others are willing
", "time": "2024-12-12T16:05:30Z"}, {"author": "Martin Duke", "text": "I can do it
", "time": "2024-12-12T16:05:58Z"}, {"author": "Brian Trammell", "text": "(might also end up lurking in the chat, I have like ten minutes of workable voice left)
", "time": "2024-12-12T16:06:12Z"}, {"author": "Hang Shi", "text": "Is the signal in SCONE superset of TRAIN?
", "time": "2024-12-12T16:11:31Z"}, {"author": "Brian Trammell", "text": "hang: Yes,
", "time": "2024-12-12T16:11:50Z"}, {"author": "Brian Trammell", "text": "in the sense you can express everything in scone that you can in train
", "time": "2024-12-12T16:12:02Z"}, {"author": "Brian Trammell", "text": "(unless train defines non-numeric signal values, in which case no)
", "time": "2024-12-12T16:12:16Z"}, {"author": "Ted Hardie", "text": "Note that one option here is to keep a restricted set of bits, but defined them in terms of feedback in a feedback loop (actions rather than predefined values). That means it is not unbounded semantically, but not going to bit-rot as speeds go up.
", "time": "2024-12-12T16:12:44Z"}, {"author": "Gorry Fairhurst", "text": "@Ted, interesting, but this needs to be coordinated between network providers and endpoimnts
", "time": "2024-12-12T16:15:40Z"}, {"author": "Brian Trammell", "text": "\"varlen is not that much more expensive\" but I have heard (in other contexts) that varlen might make certain implementations simply infeasible
", "time": "2024-12-12T16:15:41Z"}, {"author": "Brian Trammell", "text": "(\"offet fixedness\" is definitely a deployability flag)
", "time": "2024-12-12T16:15:55Z"}, {"author": "Mirja K\u00fchlewind", "text": "I think we actually don't know fully yet how much bits we need. E.g. an averaging interval might be some useful additional information. We need to do a bit more experimentation with that but I think flexibility might be key to be future proof.
", "time": "2024-12-12T16:17:13Z"}, {"author": "Wesley Eddy", "text": "+1 Mirja
", "time": "2024-12-12T16:17:29Z"}, {"author": "Ted Hardie", "text": "@Gorry they need to agree what the action means, but I think there can be some fuzziness on the actual measurement. So if you have a signal that means, grossly \"reduce by 10%\" differences in the way the measure the overall percentage probably aren't important at the \"choose the next lower video rate\" decision.
", "time": "2024-12-12T16:18:22Z"}, {"author": "Gorry Fairhurst", "text": "@Ted, for sure we don't need much accuracy, but do need a wide range.
", "time": "2024-12-12T16:19:44Z"}, {"author": "Gorry Fairhurst", "text": "+1 Mirja on maybe needing one or more params/flags
", "time": "2024-12-12T16:20:22Z"}, {"author": "Hang Shi", "text": "@Ted, I am afraid there are many different ways that the application can adpat to the signal. And applications can evolve fast.
", "time": "2024-12-12T16:20:41Z"}, {"author": "Matt Joras", "text": "It would also be a shame if that range was completely fixed in time, since we are making decisions based entirely on a snapshot of video products as they exist today.
", "time": "2024-12-12T16:20:48Z"}, {"author": "Mirja K\u00fchlewind", "text": "Actually I think we send something slower than TCP because we explicitly don't do congestion control
", "time": "2024-12-12T16:23:14Z"}, {"author": "Gorry Fairhurst", "text": "I don't see why this is ONLY downward, the envelope can indeed be increased for a mobile service.
", "time": "2024-12-12T16:23:14Z"}, {"author": "Brian Trammell", "text": "on one hand, yes, on the other hand there are bandwidth limitations imposed by the fact that most video consumption involves someone's eyes in the loop :)
", "time": "2024-12-12T16:23:27Z"}, {"author": "Hang Shi", "text": "ISTM the signal and the response can only be a rough consensus between the applicaiton and network.
", "time": "2024-12-12T16:23:28Z"}, {"author": "Mirja K\u00fchlewind", "text": "what Ted says seem to be re-inventing ECN to me.
", "time": "2024-12-12T16:23:59Z"}, {"author": "Martin Duke", "text": "@Ted my summary of your comment is not great. PTAL
", "time": "2024-12-12T16:24:22Z"}, {"author": "Lucas Pardue", "text": "we could call it explicit enshittification notification :joy
", "time": "2024-12-12T16:24:24Z"}, {"author": "Matt Joras", "text": "+1 Mirja
", "time": "2024-12-12T16:24:24Z"}, {"author": "Gorry Fairhurst", "text": "+1 Mirja. The CC will react. This isn't the problem in SCONE.
", "time": "2024-12-12T16:24:44Z"}, {"author": "Brian Trammell", "text": "on feedback: in the ABR case, isn't the feedback at the H3 layer, where the client encodes the rate of the next block in the URL?
", "time": "2024-12-12T16:25:32Z"}, {"author": "Lucas Pardue", "text": "thanks for doing this work Marcus, it helped me for sure
", "time": "2024-12-12T16:25:39Z"}, {"author": "Chris Box", "text": "I can see the value in sending an upward signal, i.e. \"There is now a lot more bandwidth here, so now would be a good time to prefetch/increase quality/etc\".
", "time": "2024-12-12T16:26:11Z"}, {"author": "Abhishek Tiwari", "text": "Good point @Chris Box
", "time": "2024-12-12T16:26:41Z"}, {"author": "Brian Trammell", "text": "+1 chris
", "time": "2024-12-12T16:26:50Z"}, {"author": "Matt Joras", "text": "+1 Chris. Another obvious reason is switching from XG to X+1G access network, or something like that
", "time": "2024-12-12T16:27:16Z"}, {"author": "Kevin Smith", "text": "+1 Chris. Otherwise my feeling (as a cellular operator) is that the quick win is throughput advice when the user is in certain conditions where they will struggle and where that is unlikely to change within a video session (cell edge, indoors) . Whereas I'd rather see e.g. L4S tackle the issue of rapidly varying signal conditions (urban environment).
", "time": "2024-12-12T16:27:42Z"}, {"author": "Mirja K\u00fchlewind", "text": "the throughput advise rate could also indicate a higher rate. So I think that is currently implicitly covered. But I agree that is a really useful signal that we should make sure to retain.
", "time": "2024-12-12T16:28:07Z"}, {"author": "Hang Shi", "text": "For the upword signal, it may be useful to add how long the high bandwidth can last to help the application determine the bitrate of prefetch
", "time": "2024-12-12T16:29:06Z"}, {"author": "Ted Hardie", "text": "I think \"upward signal\" is a bit confusing. Do you mean from the shaper to the media server?
", "time": "2024-12-12T16:30:15Z"}, {"author": "Mirja K\u00fchlewind", "text": "I wondering if the question on spoofing is actually less of a problem is the scone network devise is in the access network? Do we need to consider that deployment, which is the case we care about most for mobile network, somehow separately?
", "time": "2024-12-12T16:30:40Z"}, {"author": "Brian Trammell", "text": "I intepreted \"upward\" => \"you can use a higher bitrate\"
", "time": "2024-12-12T16:30:52Z"}, {"author": "Ted Hardie", "text": "Ah, thanks.
", "time": "2024-12-12T16:31:00Z"}, {"author": "Gorry Fairhurst", "text": "@Ted, from network element to the client i.e., who controls the media fetch policy
", "time": "2024-12-12T16:31:15Z"}, {"author": "Hang Shi", "text": "@Mirja, Why does deployment in the mobile network matter? The attacker can send spoofed signal from anywhere in the internet, right?
", "time": "2024-12-12T16:34:18Z"}, {"author": "Mirja K\u00fchlewind", "text": "but you can filter them at access network ingress
", "time": "2024-12-12T16:35:03Z"}, {"author": "Nick Banks", "text": "How does the network element in SCONE know which CID to use in the packets it sends?
", "time": "2024-12-12T16:35:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "the same as the end-2-end
", "time": "2024-12-12T16:35:35Z"}, {"author": "Martin Duke", "text": "@Matt I concede that TRAIN doesn't provide any authentication to the network elements, but it does to the endpoints, no?
", "time": "2024-12-12T16:35:37Z"}, {"author": "Hang Shi", "text": "Firewall can be deployed regardless of the access network technology
", "time": "2024-12-12T16:35:38Z"}, {"author": "Jonathan Lennox", "text": "It's sent on the flow's 5-tuple so it looks like the actual packets from the QUIC flow, unless you're specifically looking for SCONE packets on your ingress
", "time": "2024-12-12T16:35:50Z"}, {"author": "Nick Banks", "text": "That assumes the endpoint can determine the CID from e2e traffic? How does it even know the CID length in those short header packets?
", "time": "2024-12-12T16:36:21Z"}, {"author": "Jonathan Lennox", "text": "I think in TRAIN the inserted TRAIN packets had to be long header?
", "time": "2024-12-12T16:36:58Z"}, {"author": "Mirja K\u00fchlewind", "text": "yes, scone and train are both long header and then you know the CID and can map it to the e2e traffic
", "time": "2024-12-12T16:37:44Z"}, {"author": "Nick Banks", "text": "For TRAIN, the network doesn't have to worry about building packets that will correctly reach the peer. For SCONE, it does, but I still am not sure how they would do that reliably
", "time": "2024-12-12T16:37:58Z"}, {"author": "Matt Joras", "text": "@Martin my point is that there's no compelling protection from spoofing. A spoofer just needs to capture packets and then insert TRAIN as it wants.
", "time": "2024-12-12T16:38:03Z"}, {"author": "Mohamed Boucadair", "text": "@Mirja, on the filtering thing: this means that the network has to inspect every incoming QUIC packet, etc. That's an extra load/work/network impact. Not sure how this is viable.
", "time": "2024-12-12T16:38:22Z"}, {"author": "Martin Duke", "text": "If it is in the packet forwarding path, in which case it is in effect a traffic shaper, no?
", "time": "2024-12-12T16:38:42Z"}, {"author": "Mirja K\u00fchlewind", "text": "in scone there are also packets from the client to the network to indicate scope support
", "time": "2024-12-12T16:38:47Z"}, {"author": "Brian Trammell", "text": "so the fundamental question here is \"who controls the update frequency (and therefore the update latency)\"
", "time": "2024-12-12T16:39:01Z"}, {"author": "Jonathan Lennox", "text": "And it assumes there's no valid case for SCONE signals coming from outside the access network, which I'm not sure I'm willing to commit to.
", "time": "2024-12-12T16:39:01Z"}, {"author": "Matt Joras", "text": "@Martin exactly, so what is the benefit from spoofing?
", "time": "2024-12-12T16:39:07Z"}, {"author": "Nick Banks", "text": "In the case where there is migration, the network element won't be able to correlate that to any previous connection. It will have no way to know how long the CID is in those short header packets, and therefore it won't have any way to know how to build a long header packet correctly.
", "time": "2024-12-12T16:39:58Z"}, {"author": "Martin Duke", "text": "With SCONE, a node that can observe the path but not drop can send packets
", "time": "2024-12-12T16:39:59Z"}, {"author": "Jonathan Lennox", "text": "There's a difference between being able to observe the packets and being able to modify the packets (the latter being stronger proof that you could also drop or delay them).
", "time": "2024-12-12T16:40:28Z"}, {"author": "Matt Joras", "text": "with TRAIN, if you can observe and send packets, you can spoof TRAIN.
", "time": "2024-12-12T16:40:50Z"}, {"author": "Mirja K\u00fchlewind", "text": "@med I'm not saying the network has to filter but if it would send packets with the same 5-tuple itself there would be nothing that would filter it out before the client. while for not access network scenarios you might have a problem because of ingress filtering.
", "time": "2024-12-12T16:40:53Z"}, {"author": "Hang Shi", "text": "+1 on migration
", "time": "2024-12-12T16:40:58Z"}, {"author": "Martin Duke", "text": "@Matt no, a duplicate packet will fail processing
", "time": "2024-12-12T16:41:18Z"}, {"author": "Ziyang Xing", "text": "+1 on migration
", "time": "2024-12-12T16:41:21Z"}, {"author": "Jonathan Lennox", "text": "Matt: can you? I think you'd also have to be able to outrace the arrival of the valid packet.
", "time": "2024-12-12T16:41:25Z"}, {"author": "Jonathan Lennox", "text": "Because of duplicate detection, as Marin says
", "time": "2024-12-12T16:42:39Z"}, {"author": "Jonathan Lennox", "text": "At which point you're probably in the position to be able to delay packets.
", "time": "2024-12-12T16:42:57Z"}, {"author": "Brian Trammell", "text": "yeah, you need endpoint renegotiation for cid change
", "time": "2024-12-12T16:43:08Z"}, {"author": "Zaheduzzaman Sarker", "text": "I want to know the prompt for this picture ..
", "time": "2024-12-12T16:44:14Z"}, {"author": "Jonathan Lennox", "text": "I'm wondering if a hybrid would work, where sufficient information is put into an exisitng-flow packet to be able to validate that the inserted packet is valid. There isn't a lot of entropy space to play with though.
", "time": "2024-12-12T16:44:31Z"}, {"author": "Nick Banks", "text": "One more question on the SCONE negotiation topic: Do we expect there to be some type of FIN here to let the network know it should stop sending SCONE packets?
", "time": "2024-12-12T16:44:54Z"}, {"author": "Brian Trammell", "text": "nick: good question
", "time": "2024-12-12T16:45:19Z"}, {"author": "Hang Shi", "text": "this reminds of SPUD/PLUS
", "time": "2024-12-12T16:46:17Z"}, {"author": "Mirja K\u00fchlewind", "text": "\"baking proposals\" -> really funny...
", "time": "2024-12-12T16:47:02Z"}, {"author": "Lucas Pardue", "text": "funnily, I was reading https://datatracker.ietf.org/doc/html/rfc1025 just this week
", "time": "2024-12-12T16:47:56Z"}, {"author": "Mirja K\u00fchlewind", "text": "how about starting a new draft and merge the stuff we agree, rather than picking one to start with?
", "time": "2024-12-12T16:49:06Z"}, {"author": "Hang Shi", "text": "+1 Mirja
", "time": "2024-12-12T16:49:26Z"}, {"author": "Zaheduzzaman Sarker", "text": "Please take the proposal to the list and agree there what to do
", "time": "2024-12-12T16:50:28Z"}, {"author": "Martin Duke", "text": "Can someone cover me while I get more coffee?
", "time": "2024-12-12T16:51:28Z"}, {"author": "Martin Duke", "text": "(on the notes)
", "time": "2024-12-12T16:51:31Z"}, {"author": "Ted Hardie", "text": "Will do
", "time": "2024-12-12T16:51:55Z"}, {"author": "Qin Wu", "text": "thanks Ted
", "time": "2024-12-12T16:52:20Z"}, {"author": "Martin Duke", "text": "@Ted, I'm back, thanks
", "time": "2024-12-12T16:54:03Z"}, {"author": "Matt Joras", "text": "@Martin @Jonathan re: racing I think that's right, but having access to inject packets and read packets is already an strong position for an on path attacker.
\nThere is no protection inherent in TRAIN to say \"This packet is guaranteed to only have the TRAIN added by the endpoint\".
", "time": "2024-12-12T16:55:21Z"}, {"author": "Martin Duke", "text": "I agree that the elements have no assurances
", "time": "2024-12-12T16:56:09Z"}, {"author": "Martin Duke", "text": "but the signal will go to the receiver, which will toss the packet if TRAIN hasn't been negotiated
", "time": "2024-12-12T16:56:55Z"}, {"author": "Martin Duke", "text": "the attacker can't even ascertain the advice
", "time": "2024-12-12T16:57:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "if the client did not send a scone packet first, it will also ignore all packets from the network
", "time": "2024-12-12T16:58:24Z"}, {"author": "Matt Joras", "text": "What's the benefit of that? With SCONE, inherently there's no required participation of the destination endpoint. The client endpoint is the one that broadcasts it supports receiving the advice.
", "time": "2024-12-12T16:58:26Z"}, {"author": "Martin Duke", "text": "well the benefit is that the data is more secure. the downside is it requires client and server cooperation
", "time": "2024-12-12T16:59:25Z"}, {"author": "Martin Duke", "text": "or maybe that's a benefit, depending on your privacy perspective
", "time": "2024-12-12T16:59:43Z"}, {"author": "Mirja K\u00fchlewind", "text": "not sure if that's actually more secure
", "time": "2024-12-12T16:59:47Z"}, {"author": "Matt Joras", "text": "+1
", "time": "2024-12-12T16:59:51Z"}, {"author": "Martin Duke", "text": "I'll compose an email on the list, we're being too noisy
", "time": "2024-12-12T17:00:24Z"}, {"author": "Mirja K\u00fchlewind", "text": "thanks!
", "time": "2024-12-12T17:00:41Z"}, {"author": "Ted Hardie", "text": "The benefit is that the client and server both are aware that the set of choices being made are affected by the existence of the shaper. In some cases, the server might take actions to adjust the set of choices available, though that really comes in if you have the shaper able to communicate the constraint to the server as well as the client. That was discussed at the IETF meeting, but it isn't in the proposals right now.
", "time": "2024-12-12T17:02:06Z"}, {"author": "Mirja K\u00fchlewind", "text": "I don't see that as a real benefit because usually the server and client are under control of the same entity anyway
", "time": "2024-12-12T17:03:00Z"}, {"author": "Ted Hardie", "text": "@Mirja then you never want this usable by a browser?
", "time": "2024-12-12T17:03:29Z"}, {"author": "Hang Shi", "text": "can the client tell the server through HTTP layer?
", "time": "2024-12-12T17:03:36Z"}, {"author": "Matt Joras", "text": "@Ted I don't think anyone intends the server to be using SCONE to change client behavior. it is giving the network the ability to change client behavior.
", "time": "2024-12-12T17:03:49Z"}, {"author": "Mirja K\u00fchlewind", "text": "if we have a browser we need some new exposure interface anyway
", "time": "2024-12-12T17:03:58Z"}, {"author": "Matt Joras", "text": "If the server wants to change client behavior it would use an application signal instead
", "time": "2024-12-12T17:04:02Z"}, {"author": "Martin Duke", "text": "there are only so many browsers and I imagine they will all support this if we're successful
", "time": "2024-12-12T17:04:06Z"}, {"author": "Matt Joras", "text": "and especially with TRAIN, why would a server restrict itself with 6 bits of signal when it can send arbitrary information in the encrypted envelope?
", "time": "2024-12-12T17:04:50Z"}, {"author": "Ted Hardie", "text": "@Martin I agree, but the control of the browser and the service is not unified except in specific cases. That's the point I was replying to.
", "time": "2024-12-12T17:04:55Z"}, {"author": "Ted Hardie", "text": "@Matt because we're talking about the data it could get from the network element (though you could obviously have the client reflect it to the service over the encrypted channel, at the cost of some latency)
", "time": "2024-12-12T17:05:55Z"}, {"author": "Matt Joras", "text": "Yeah I'm not sure that's so compelling in most real world video deployments. The \"endpoint\" server in a lot of cases is a \"dumb\" CDN node, not one that is actively participating in the video playback.
\nSo the client getting signals to the \"video endpoint\" often requires an application level signal anyway, rather than a signal just to the first hop.
", "time": "2024-12-12T17:07:44Z"}, {"author": "Ted Hardie", "text": "That's a fair point.
", "time": "2024-12-12T17:08:39Z"}, {"author": "Zaheduzzaman Sarker", "text": "I think the discussion should cover two aspects - 1) what the client needs from the network and 2) what the network can provide.
", "time": "2024-12-12T17:08:59Z"}, {"author": "Brian Trammell", "text": "+1 zahed
", "time": "2024-12-12T17:10:50Z"}, {"author": "Lucas Pardue", "text": "a lot of folks just use a library for their ABR stuff. Configuring it, slapping their own business logic outside. Common examples being dash.js, hls, js, exoplayer etc.
\nThe'y be running their own client-side logic for things like bandwidth estimation etc. So a survey of what they already use, and could take from the network rather than locally compute, might help us. Whether such a survey is already available in literature - I don't kn ow
", "time": "2024-12-12T17:13:50Z"}, {"author": "Lucas Pardue", "text": "I would add NRLP to the list. The required configuration to provide SCONE can be found at: https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery/blob/main/example-nrlp-wire-format.md
", "time": "2024-12-12T17:19:18Z"}, {"author": "Brian Trammell", "text": "(+1, thanks for the last minute proposal and pulling this together!)
", "time": "2024-12-12T17:20:59Z"}, {"author": "Mirja K\u00fchlewind", "text": "for performance impact there are two cases: if you do throttling today, probably the performance improves. If you just compare scone to doing nothing of course the is an impact but given this will usually be done close to the client in the access network, the impact is probably not bigger than other stateful things like NAT
", "time": "2024-12-12T17:28:35Z"}, {"author": "Zaheduzzaman Sarker", "text": "That all for this virtual interim!! Things look promising from here .. :-)
", "time": "2024-12-12T17:29:10Z"}, {"author": "Martin Duke", "text": "On time! great job, chairs
", "time": "2024-12-12T17:30:10Z"}, {"author": "Kevin Smith", "text": "Thanks Brian and Qin and all the presenters :)
", "time": "2024-12-12T17:30:34Z"}, {"author": "Ian Swett", "text": "https://datatracker.ietf.org/doc/html/draft-rjt-scone-conformance-signal-00
", "time": "2024-12-12T17:31:00Z"}, {"author": "Marcus Ihlar", "text": "Thanks everyone!
", "time": "2024-12-12T17:31:08Z"}, {"author": "Mirja K\u00fchlewind", "text": "bye
", "time": "2024-12-12T17:31:18Z"}]