Random Qs for IETF-120 BoF

[jlivingood]

If it is useful to communicate maximum available bandwidth, what other attributes may be useful to communicate? Maybe stuff like:

• Advertised/marketed bandwidth
• User CPE protocol version (i.e., DOCSIS 3.1, 10 EPON, 25G PON, 5G, 4G)
• User device/CPE maximum bandwidth (i.e., 100 Mbps, 1 Gbps, 2.5 Gbps)
• Link layer type (i.e., LEO, DSL, PON, DOCSIS, 5G)
• Mobility indicator (i.e., fixed, mobile)

[jlivingood]

• Expected jitter
• Expected working latency
• ?

[SpencerDawkins]

We should at least characterize the properties we're thinking about. Just looking at Jason's list, includes attributes about policies, and about specific technologies, and about network engineering aspects.

A complete list of attributes is probably premature, and is probably up to the working group after it's formed.

[danwing]

But let's not characterize things such that they get all borked up. For example, should a 5G "hot spot" device claim it is "mobile" (it's light, it could be powered by 12V socket in a car or a power brick), or is it fixed because it is marketed as a home Internet solution (which is not mobile). And then there are situations such as cruise ships and RVs where the Wi-Fi hot-spot provided by the vehicle changes from satellite (or cellular) to something more fixed when the cruise ship or RV has stopped in port or at a campground; the client would need to be updated with this change. Supposedly the other characteristics change, too -- more bandwidth, less delay, better jitter among other things.

I think it comes down to: can the client do something useful with the knowledge. That is, is there a use-case. Telling the client it is 5G or 6G or DOCSIS 3.0 doesn't help the client unless it has a map of those layer 1 and layer 2 technologies to a capability set, and there is a way for the client to interact with that capability set. I assert the mapping to layer 1 and layer 2 technologies should happen at a higher layer, such as SCONEPRO (because I am here commenting on SCONEPRO).

[fluffy]

For the uses cases we have been talking about of improving user experience for things like ABR video, I don't think any of these help. It would be amusing to see an answer come back from that said "advertised bandwidth = 100 Mbps, actual max bandwidth =15" (yah, I'm on Telus DSL today) but I don't think that is the problem the WG is solving

[fluffy]

For thing like "expected jitter", I don't see how the network would ever have any clue of the what the expect jitter would be

[jlivingood]

They key initial use case is in the mobile wireless networks. But at root this seems to be how a network can expose an attribute or set of attributes to apps like ABR video for them to leverage it as they see fit. In the ABR case that is for use in real-time flow shaping but it could also be used in post-session analysis and so on.

Some examples:

• Could an in-app-session test of capacity/speed or working latency want to know the advertised speed of the connection or expected typical working latency? I could see a speed test then using it to say you got x% of advertised or an app using it to flag that someone is getting poor throughput and thus poor app QoE and prompting them to troubleshoot WiFi or whatever.
• Attributes like link layer protocol and so on - maybe that is useful to append to session QoE data for app developers? Perhaps in the long term there may even be different adaptations for each of these, to maximize QoE for a given attribute?
• Device max bandwidth may well be below what the network communicates as the preferred shaping rate or max bandwidth for a given app.

Anyway - just throwing out ideas of other attributes we may want to expose if there is a mechanism developed at IETF to do so. I guess not needed for the BoF, but whatever mechanism is developed in a WG - would be nice to allow it to be extensible to handle other network and device attributes.

[SpencerDawkins]

This is excellent discussion (so please keep up the good work between now and IETF 120), but it's highly relevant to #88, and the associated PR #93.

[SpencerDawkins]

Just to follow up on my previous reference to PR #93, I should point to this line in that PR:

The following topics are out of scope for SCONEPRO:

1. Support for streaming video flows carried in other transports and substrates. SCONEPRO is focused on streaming video carried either directly in QUIC, or indirectly in QUIC, as through HTTP/3.
2. Support for other media types that would require awareness of additional network attributes beyond the attributes applicable to ABR video.
3. General extensibility to support other network attributes. If additional network attributes are identified, the working group will request recharter to add them to SCONEPRO.
4. Any aspects of fine-grained congestion control signaling. This is in scope for existing IETF working groups now.

Other folks (I'm looking at you, @zaheduzzaman!) can correct me on this, but ISTM that we're tussling between

• OF COURSE we want to be able to add new attributes as necessary, but
• We've spilled a lot of blood, mostly not literally, over concerns that excessively extensible protocols can unmask a lot of security issues, and especially privacy issues.

If the proposed text in #93 sticks, we'd be able to design a protocol that is extensible for new network attributes, but we wouldn't extend the protocol to support new network attributes without adult supervision from the SEC folks, the IESG, and the IAB.

So, nailing down attributes that everyone agrees would be useful, even if some of them aren't useful in every case (see previous discussions about attributes that are useful in mobile networks, but not elsewhere), so that the charter review and balloting process can take security and privacy concerns into account, without worrying (quite as much) about a later extension opening a new Pandora's box without anyone noticing.

Does that help?

[SpencerDawkins]

> And then there are situations such as cruise ships and RVs where the Wi-Fi hot-spot provided by the vehicle changes from satellite (or cellular) to something more fixed when the cruise ship or RV has stopped in port or at a campground; the client would need to be updated with this change. Yes, on this. It does seem like we're tussling between network attributes that change very slowly over time (some people are thinking they can use SCONEPRO to tell UEs what to expect based on policy, and that expectation would only change when policies change, while other folks are thinking they can use SCONEPRO to tell UEs about network attributes that change more frequently). So clients ought to expect that a SCONEPRO monitor would provide updated network attributes "from time to time". I love the cruise ship WIFI flipping between satellite and harbor cellular example - the UE can reasonably expect that this will change at least twice during the duration of the cruise (leaving port, and re-entering port), but if you're flipping back and forth every five seconds for any length of time, users on the cruise ship may be having bigger problems than their UEs finding out about changes in network attributes. :grinning: > **I think it comes down to: can the client do something useful with the knowledge.** That is, is there a use-case. Telling the client it is 5G or 6G or DOCSIS 3.0 doesn't help the client unless it has a map of those layer 1 and layer 2 technologies to a capability set, _and_ there is a way for the client to interact with that capability set. I assert the mapping to layer 1 and layer 2 technologies should happen at a higher layer, such as SCONEPRO (because I am here commenting on SCONEPRO). I broadly agree.

[jlivingood]

General extensibility to support other network attributes. If additional network attributes are identified, the working group will request recharter to add them to SCONEPRO.

Missed opportunity.

You should put that forward at the BoF as a question.

[mwelzl]

Perhaps there could be a statement about the expected time frame? E.g., congestion control signals tend to be more frequent than one signal per RTT; then again, being super infrequent may become a problem in scenarios with dynamic routing, various wireless handover scenarios, etc. How about saying something like: "The signal is expected to be requested and conveyed at most once per round-trip time." ?

So, about the actual signal and the question in this issue. Considering past failures of network-host signaling (I'm thinking of SPUD and its several incarnations, and TrigTran long before that), I think the story was always:

• Generally, this would be good (yes we can all agree here),
• But let's dig down into specifics: what exactly would you do with it?
• ... and then failing because there wasn't a good answer. TrigTran tried to have a concrete one but that was flawed, as RFC 9049 explains.

In SPUD's case, the resolution was to bring in ISPs who say "hey, we totally prefer this signal over having to do DPI, and identifying your traffic can help you!", which wasn't too convincing for the "pervasive monitoring is an attack" crowd.

I like some of the ideas that are mentioned in this thread! E.g., "mobility indicator" - but this should probably be worked out with an example: how exactly would the signal look, what exactly would an end system do with it? I guess knowing something about the stability of capacity (is there a wireless that's permanently fluctuating or are things more stable?) could be useful too. But, again, it should probably be worked out to make it clear that there's a real benefit to the signal.

Frankly, personally, I think the "maximum available bandwidth" use case is pretty lame (sorry). It's so easy to figure this out with various probing approaches that it's probably the least interesting signal an end system could wish for.

[mjoras]

Frankly, personally, I think the "maximum available bandwidth" use case is pretty lame (sorry). It's so easy to figure this out with various probing approaches that it's probably the least interesting signal an end system could wish for.

@mwelzl I think this is a misunderstanding of the signal being proposed. We are not proposing simply detecting the existence of e.g. a policer, but offering an alternative in which the endpoints cooperate with the network so the network does not need to police. See this thread on the list for more details.

[mwelzl]

Okay, I think I got it now (and sorry: I had seen that thread but read it too quickly): the difference is that it's not just an informational signal to the endpoints, but that the endpoint will behave accordingly and hence shapers don't need to shape anymore. This will need secure per-flow signaling back to the shaper to say "got it; no need to shape my traffic, trust me". That's a different thing, yes, if you can pull this off.

[SpencerDawkins]

I'm just cleaning up open issues, and my thoughts on this one are

• @jlivingood's list of attributes in comments https://github.com/mjoras/SCONE-PROTOCL/issues/87#issue-2396614129 and https://github.com/mjoras/SCONE-PROTOCL/issues/87#issuecomment-2215384211 are important, but
• the current SCONEPRO proposed charter explicitly says

This working group will not produce a solution that:

(snip)

Is appropriate for use as input to a congestion control algorithm

For this reason, I think this issue can be closed as "wontfix".

@martinthomson and @fluffy, do you agree?

[fluffy]

Here is my best read on the consensus on this one. Having talked to a bunch of people on this and reread all the input...

I think the consensus is that these should not be in the initial charter. If they turned out to be a need for them, we could consider adding them later. So I am going to close this with "not now"