Name: Securely COmmunicating NEtwork PROperties (SCONEPRO)
IETF 120, Vancouver
Regency C/D at 09:30-11:30 (UTC-7)
Chairs: Cullen Jennings, Martin Thomson
Scribes: Alan Frindell, Wes Eddy
The chairs reviewed the set of I-Ds related to SCONEPRO.
Review of BoF Goals / Questions
ABR Video shaping is a common practice
Reduce volume of flows that can adapt
Manage load, differentiate subscription tiers
Clients continually measure network conditions and select the best
quality that won't stall
Shaping tries to force a range of quality so the player will adapt.
It works but...
Proposal: Explicitly inform what bitrate can be supported
Application can adapt directly
Congestion Limited -> Application Limited
May allow removing shaping in your network
Discussion has occurred on mailing list, and on github.
8 drafts with sconepro, many addressing questions from previous BoF.
Working on proposed charter, has changed significantly, both since last
Bof and in the last couple weeks in particular.
Please identify anything the proponets have missed
Network to host signalling
Relevant to all networks, not just mobile
Out of scope items listed in charter
What could this be used for outside the stated goal?
Target is ABR over QUIC, properties = maximum achievable thoughput
What are the implications of this work?
This is opt-in, from the client
Information flowing from network to client
The only information coming from the client is that this is ABR video
This is already there today. Operators have to know this.
Managing video load is important.
Operators look at things like SNI today
No new information is introduced
Privacy Analysis would be a key function of the wg
How can I trust this information?
What properties can't be a achieved? Some of this is addressed by PoC
presented at 119.
What could be problematic? What do you need to trust?
Sconepro is optional and advisory. This is not required. Can choose to
ignore or trust as it sees fit.
Video Users -> shaping and policing leads to poor video outcomes
Content Providers -> equal opportunity for smaller providers
Carriers and Operators -> Traffic shaping is expensive (computation,
maintainability). Moving targets.
Are we doing the right thing? Chairs will ask.
Proponents don't belive sconepro changes anything.
It's a response to existing systems.
Are we doing the right thing? Chairs will ask.
Martin Duke: Client must be ABR? Is this going to be in the charter and
intended to be enforced somehow?
Matt Joras: Yes it's in the charter; but we have not thought about
enforcement. It is advisory information - if a client or network is
lying, there are mitigations.
Cullen Jennings: Asked Martin to clarify.
Martin: Asking if someone can opt in for something that isn't ABR? There
is no provacy exposure
Lars Eggert: Good presentations. Good job.
Inverse of Martin's question: no other information flows up? Is any
subscriber information exposed? Could an operator only expose this
feature to some customers?
Matt: This would not have subscriber information in it? Could an
operator choose to not do this for some flows? Yes, like today they can
not shape a flow.
Lars: Not shaping makes it better. You have the ability to exclude the
client from the better service that this offers. Would prefer that
operators can't omit the signal.
Q Misell: Is ABR the only thing being considerer or are there other
network properties considered?
Matt: Charter exclusively targets ABR over QUIC. Could include video
calls. There is thought work about other properties but not included.
Q.: This is a limitation that shouldn't be there.
Is this request for information linked to a flow?
Would there be a possibilty for the operator to disable or use a
different shaper if the client asked.
Matt: It would be associated with a flow.
Q.: You could have different properties for Disney+ or Netflix. Think
about it.
Watson Ladd: Is this a mechanism to communincate the limits beyond what
is experienced within congestion?
Matt: this is not meant to replace congestion control or something that
feeds into congestion control. It's higher level, and we'll talk about
it later.
Toerless Eckert: What does ABR mean? Everyone who runs a service has a
different definition. Please be descriptive. There's difference between
VC and 10s playout.
Matt: These are both in scope.
Luis Contreras: Privacy from perspective of the provider? Re: Net
Neutrality, needs to be explored with more detail. Need to provide the
same behavior to whatever application.
Matt: We haven't thought much about the privacy model from the operator
side. Net Neutrality - large topic. IETF isn't a regulatory or policy
body -- makes it tricky. It's not protocol or internet engineering.
Luis: Understanding the implications is a matter for the WG.
Cullen: protecting the privacy of the rate - this is revealed today by
speed test.
Martin: is the problem statement clear?
Ian Swett: multiple times Matt said "Client side ABR", what about server
side ABR. Should be ok - we need to be clear. The limitation is not on a
client.
Martin:
Toerless: There is not even hand waving about what is the best we can
achieve without SCONEPRO and things that are less invasive.
Martin: is this a clarification question.
Toerless: it's handwaving.
Glenn Deen: Putting ABR in the charter won't help. This mechanism is
something that implementations use today, but maybe something different
in the future. Maybe make ABR an example.
Martin: Charters are temporary.
Glenn: Charter may last longer without restriction to ABR.
dkg: "The client" is unclear. Current schemes are about identifying
user. Mechanisms that identify people are problematic. Hope this is not
in the direction.
Suhas Nandakumar: Charter looks fine. This should not be mobile only.
Chairs: This is addressed later in the charter.
Martin: client may not be right, hold that.
Lars Eggert: Why only QUIC-based?
Martin: QUIC for now.
Lars: "QUIC initially", or something.
Stephen Farrell: "Same communication channel" - same as what?
Martin: Needs to be worked out?
Stephen: we don't know?
Martin Thomson: Matt's strawman shows same UDP flow
Cullen: Charter doesn't satisfy. Both types of solutions are viable.
Stephen: Can this sentence be deleted?
Marcus: Client identifies itself on some channel and the response comes
back in the same channel. Does this make it more clear?
Stephen: Clearer but more icky.
Toerless: The place where this magic needs to happen allows for per-flow
shaping or policy? This is fine as a solution. Will charter bash.
Martin Duke: Slide doesn't match words. Connections or UDP 4 or
5-tuples.
Martin Thomson: The wg needs to work this out.
dkg: same Q as Martin Duke. Quic connection means something. If this is
related to QUIC connections and we do something else, that's weird. QUIC
streams could be "flows" and QUIC connections can move over different
tuples.
Matt: Spending too much time here. This is something that changed
recently.
Cullen: Does changing this to QUIC connection help?
dkg: QUIC is supposed to not be able to distinguish flows within a QUIC
connection.
Jon Varsanik: Previous slide: what is maximum achievable throughput?
MT: Working group will decide. Maximum achievable throughput is "messy".
Squish is involved in certain network environments and sometimes people
exceed the limit. This is in scope for discussion
Christian: QUIC connection is cool. Does it include QUIC Multipath?
MT: We are shelving this topic for now.
Gorry: Is it a maxmimum for a path or the flow.
MT: Good question, we will come back to it.
Toerless: Is there any time over which the number is given.
MT: unspecified in the charter. Longer timescale than CC works on. (one
or a small number of RTTs)
Toerless: Please put this in the charter.
MT: This is reasonable.
Mirja: We don't need which packet belongs to which connection. We want a
solution that works for QUIC traffic.
on-path, optionality, not directives
Lars: is there no access control? Does it matter if it's on path?
MT: put a pin in, we will come back.
resilient to nat-rebinding, scalability, security
Stephen Farrell: We might or might not do some security stuff.
MT: we should definitely do security stuff.
Stephen: The wg will think about it?
Lars: May invoke != must use.
Ben Schwartz: If we're not moving sensitive info, let's not add security
stuff. The wg will think carefully about security and that's it.
MT: it would not be good of random off-path actors can send these
signals.
Ben: TCP style style security is good, yes.
Christian: Strike #7. QUIC is designed so that paths that are different
cannot be correlated. We should not say that in the charter. We cannot
break the privacy properties of QUIC.
MT: leave this for discussion.
Marcus: The client should be able to get different signals from
different paths.
video flows in non-quic, other media types, other network attributes,
congestion control
Alex Chernyakhovsky: Uncomfortable with QUIC only/
MT: come back later.
Yaroslav Rosomakho: Is bidirectional media in scope?
Cullen: Bidirectional is in scope? Head nods.
Yaroslav: Please clarify in text.
Glenn: Is a playback scenario with a manifest with different sources
(eg: content vs ads).
Cullen: This is in scope? head nods.
Glenn: Is it explicitly out of scope for extensible attributes.
MT: Explicitly out of scope.
Gorry: What is rate adaptation? (question is on rate adaptive
applications versus transports)
MT: This was intended for clarifying CC.
Tom Hill: What do we mean by congestion signalling being out of scope?
There's a difference between how we deal with artifical limits
(shaping/policing) and signalling back inherent variability. Available
capacity fluctuates. Can we signal that bandwidth is about to disappear.
MT: There's a line that is difficult. The idea of a charter is for there
to be a guideline. The WG will find the line. That is healthy. We're not
doing ECN.
Cullen: This is the maximum
Tom: The maximum can change significantly. We have knowledge in advance.
Is that out of scope?
Luis Contreras: Clarifying max is the only property in scope
Martin Duke: Is there enforcement that it's QUIC only?
MT: no
Christian: Sad that there is nothing about ECN
MT: This does say something about ECN - congestion signalling.
Christian: There can be a conflict between ECN and this signal and it
needs to be addressed.
Cullen: a max doesn't change your CC
Christian: The wg shall address this issue.
MT: Please suggest text.
Matt: ECN is about congestion (it's in the name). This is an application
signal and they are composable.
Christian: the expectations should be expressed
Chairs: we need to move on
Mo Zanaty: Confused that this is bidirectional? Will there be two
bandwidth's signalled? If so, you need to clarify.
MT: There's a note to clarify this. Moving on.
Toerless: what is the difference between a protocol and a mechanism? Is
ECN a protocol?
Room: some yes, some no. Laughter.
Gorry: Protocols have mechanisms.
Cullen: we will wordsmith better.
dkg: This is a fundamental problem. We don't agree on what we're talking
about. This has happened before. Part of the design of quic is to
obscure which flow is which from the operator. We are chartering a group
that is going to signal which flow is which, explicitly for QUIC.
Cullen: The room is shaking heads. You are right that we have different
ideas.
Spencer: Applications -> QUIC Connections (we know what those are). Flow
needs to go away completely. This is not making any assertions about
anything inside a QUIC connection.
Zahed: What is dkg saying? We designed QUIC so that anyone in the path
doesn't know, but this signal will identify.
dkg: QUIC connections can use different connection IDs. Operators cannot
distinguish streams inside. We are chasing something that does not
exist.
Zahed: Please clarify.
dkg: If this is coupled to a connection ID, that's something different.
Cullen: How should we rephrase this?
dkg: The proposed signal is that a client that uses a quic connection,
may signal that a connection may contain ABR. Then the operator has the
opportunity to signal back limits. That is a coherent frame. It has
nothing to do with "flows".
Matt: That this the intention.
dkg: it is deeply weird to say video and not ABR. Eg: high bandwidth
stream of financial data.
Matt: This is limited to video because that exists today. Your example
is not existent. The more generic problem is harder to charter clear
scope.
Gory: max bitrate enthusiast. We don't know what the pipe contains.
Cullen: Will change to ABR traffic where it's relevant. No intention to
look inside a QUIC connection.
Gory: what if there's more than one box?
MT: There will be a limit to what this technology can do.
Martin Duke: associate with dkg. Concrete proposal: replace QUIC
connection and replace with UDP 4 tuple that carries QUIC.
Cullen: Any objections? Let's work with this.
MT: UDP 4 tuple rules out connection ID - ok? nodding heads. Flow
labels? all good? That was easy. Please use this definition moving
forward.
Suhas: definiton is QUIC path. Given this is advisory, if the app mixes
ABR and non-ABR, that's there problem. Keep at path/4 tuple level.
Q Misell: This is entirely advisory. Why do we need to make any
connection to a 4 tuple, if the client can just ask the network "what
bandwidth should I use to connect to netflix"? Why does it need to be
connected?
Cullen: Related to security properties - device providing the signal has
ability to enforce. Plus discoverability.
Watson: People are discussing solution instead of charter. The wg should
decide 4 tuple vs flow, etc. This is not another ECN, but we do want
pacing to be aware of the max in longer time scales.
Phillipp Tiesel: Do we need the flow associativity to solve the problem?
What we really need to define the problem. The charter doesn't talk
about the whole path vs the last part of the path. Try to understand the
problem not the soltuion.
Pete Resnick: #3 - the network does a lot of work in the text. Are we
talking about the whole path, etc?
Lars: Is the information comes back from the network related to the
quic-carrying-4-tuple or something else? If so, you might get better if
you can open more 4-tuples. This should be in the charter.
Mike Bishop: The parties in this protocol have different things they can
see. We don't need to mention this in the charter other than as
motivation. What we are asking for is something for the client to send
something down the network path - if you are imposing characteristics on
this path, please tell me. Everything else is motivation but may not
belong in the charter.
Toerless: We need a stronger problem statement in the charter. One that
explains why this is necessary as opposed to existing technologies (ECN,
L4S). I understand the answers, but the operators have to pay more
money, so why do they need to. Most people don't understand ABR
(burstiness). The problem statement doesn't explain.
Mo Zanaty: May be able to remove policers. I don't think this is a real
possibility. Everyone is unlikely to change anything they do. Keep that
in mind. Which networks, which rates, how many rates? Single
communication channel for both client initiation of application flows.
Dennis Jackson: Agree with dkg concerns.
Stephen: There was a suggestion in the chat about a one-shot approach,
and if that's feasible, that would be a good way to go.
Cullen: Is that chat proposal that the client should receive this info
unsolicited.
mnot: The flow association allows the network to discriminate between
flows and impacts NN.
Cullen: This is all done today. They are just now reporting. Do you want
to change somehting?
mnot: it's not well motivated. How does this interact with privacy
proxies - does it disadvantage those? The proponents want to divert
flows into a proxy - [not anymore]
Matt: Carriers are discriminating on a per 4 tuple basis today.
mnot, off mic: this codifies it
Marten Seemann: we are seing more masque deployment. Everything coming
off my phone looks like a single 4-tuple, but has flows from different
apps. Binding this to the flow is not the right abstractionl. What we
are really talking about is a limit assocaited with a subscriber. We are
mentioning the flow here because we are transport people.
Ted Hardie: not a transport people.
Sugested text: "A network communicates applicable properties of the path
as it relates to a specific user. This ensures that the user's
applications can easily access the path effectively."
Yaroslav Rosomakho: client -> endpoint. singalling to servers could be
valuable if bidirectional video is in the charter. Instead of operator,
talk about network. Produces a valuable signal for multipath selection.
Martin Duke: If it's an IP address pair or tuple, the network is
assigning this to you for all connections. Re: masque - token bucket
filtering when everything is a single connection. No mention of a
discovery mechanism - is it in scope?
MT: this will be part of the protocol.
Mo Zanaty: The charter should not talk about associativity or
subscriber. The fundamental thing is the entity wants to signal the max,
and it should indicate what the limit applies to. Don't burn granularity
into the charter, but must be signalled.
Benjamin Schwartz: As an observer, video is extra special. Video systems
will use all available bandwidth if allowed. This is different from file
transfer etc. It uses data in the network differently. We can't speak in
general terms. There are policies specific to video on the network.
There are hints in the charter that the client is going to attempt to
comply, and the network may adjust it's behavior. This should be clear.
David Schinazi: privacy proxy enthusiast. This can be used for many
things, but video is the problem we're facing today. Operators rate
limit because video is a high percentage of traffic. There's a real
problem that needs solving. Designing for video makes sense.
A user is a vague concept from the network. Can be a household behind a
NAT. One can be a video flow. Regular browser traffic can be burstier.
The shaper today only applies to some of these. Drop the notion of QUIC
connections - privacy concerns are true. Some proposed solutions don't
violate this. Supportive of this work, massage the charter.
MT: the charter won't be approved by the room. We need to update the
charter.
Cullen: want to confirm consensus -
Be clear this is moving to UDP 4 or 5 tuple, and there is no
intention to look inside what QUIC is protecting.
[no one in room seems to object]
Does the client even need to reveal to the network that it is
interested, or does the network always reveal?
Can we change the charter such that the client will receive this
unilaterally.
Mirja: not in charter, leave to WG
[some other agreement, also disagreement (Stephen Farrell had opposite
opinion)]
Spencer: If this is bound to a QUIC connection, how would it work?
Mirja: can't put this in charter.
Stephen: if we aren't sure there's a way to do this, we shouldn't
charter anything.
Mo Zanaty: Unsolicited doesn't mean client didn't send a packet.
Scone-aware client can receive a signal on every connection it makes.
Removes concerns about privacy and abr video scope.
Q Misell: When does the signal arrive? You can ask for information "over
here". This shouldn't go in the charter.
Daniel Gillmor: Mo gave a good point. We need to know the scope with
whatever the shaper is connected to. The on-pathness of the indicator.
Behind a NAT, you don't even know what tuple it applies to.
Hang Shi: it's very difficult for the network to send this to a random
client IP device.
Show of hands: Should the IETF work on this problem?
Yes: 43
No: 11
No Opinion: 19
Total In Room: 119
Zahed: Poll shows interest, charter needs work. We will do that.
Feedback has been constructive, thank you.