SCONE WG Minutes IETF 123 Madrid
Chairs, 10 minutes
Need more attention on the applicability statement charter item.
Wesley Eddy, 15 minutes
10/10 no comments
Anoop Tomar, 15 minutes
Martin: So are you recommending a new constant, or something that is
app-dependent?
Anoop: A new constant
Martin: Great.
Mo: the whole purpose of scone was to remove the pacers. what resource
are we trying to protect at a 120s interval? How do we
Anoop: It's not about giant bursts, it's about the application doing its
own pacing. this is about data plan enforcement, not resource
preservation.
Marcus: It's mostly policy, yes. What is the conformance window? If
there's a big spike, must I be silent for some time?
Brian; Do we need a separate issue for that?
Marcus: We'll discuss it.
Eric: One provider had a 120s quantum, resulted in very bursty traffic.
It broke QoE. This makes it very hard for users to recover.
Chris Box (BT): we don't really throttle, but we plan capacity. i
wouldn't have a problem with a long duration. Setting SCONE limits
affects the tonnage we expect and provision for.
Martin Thomson and Marcus Ihlar + the whole WG, 55 minutes
MT: (for editors) -- more important to have an answer than any specific
answer. Do people agree?
Kyle: are we indicating the client understands SCONE, or anything more?
Marcus: correct
Mirja: let's experiment with a signal. guidance about usage can come
later?
MT: not the point. Is this a dealbreaker?
Mirja: the fear is it's a dealbreaker for deployment
Sanjay: it's a dealbreaker for us
Brian: do you believe it is necessary to require SCONE clients to
indicate?
Matt: No, this is an optional feature for expedited deployment. clients
SHOULD do it on all QUIC flows. This is a carrot for operators to deploy
network elements.
MT: we would only do that if it was necessary to use scone
Mirja: now i'm sad. everyone needs to see an incentive.
Question: should SCONE allow first-client-packet indication with "SHOULD
indicate" language? 22 yes, 8 no, 5 no op
Ben: I don't understand why this is valuable for operators?
Matt: It saves them a trial decryption, on faith that the client will
honor SCONE.
DKG: This mechanism is "don't apply a shaper to me?" I don't think
operators will believe me
Mirja: no, it's "feel free to apply a shaper"
Tommy: this signal will degrade very quickly if universally marked.
Brian: everyone indicates but no one supports SCONE?
Tommy: Maybe we need to flesh out what is to be done with this.
Marcus: the action is to not do DPI.
Tommy: I don't like that this is a permanent signal for a temporary
transition problem
New question: "Should SCONE include first-client-packet indication of
SCONE support?" Yes: 18 No: 10 No opinion: 5
Dan Druta (AT&T): Knowing as early as possible allows network operator
to make decisions. Early indication allows him to make an early
decision. Sees SCONE as an indication that the application would comply.
Mirja: We won't converge on every QUIC connection indicating this. Make
the signal explicit.
Kazuho: I was previously opposed. Appreciate improvements to privacy.
Pure SCONE is a huge step for operators. The indicator allows them to
gradually change.
David: I break DPI all the time in Chrome. The indication needs to mean
something. "I can parse headers" is not useful.
Tommy: Maybe this marking is not the best way to have this goal? It's
not valuable to just say "SCONE doesn't make me crash".
Christian: Agrees with Tommy. Other points are that application
shouldn't hog bandwidth, and networks should not differentiate between
users. Does not think that SNI use is stable. Using this has to be a
clear win-win for everyone.
Martin D: Process suggestion and opinion. I find this to be very hard to
follow (have been to all the meetings); detect some arguing that's not
all about the same thing. Would like to see a thorough analysis over
something concrete. (need to read the PR / GH issue offline)
Brian (chair hat): thinks there's a rough-ish consensus that it's
probably useful to do something. We should take input from this
discussion to turn into a PR that can be decided on at the next interim.
We are going to have first client packet indication in SCONE and
determine the deployment considerations; is that a deal breaker for
anyone? (nobody indicated it was)
This is about what the throughput advice really means (how is it
measured, and how to conform).
Martin T: probably policing/shaping should start at the point of
detecting violation; if it can be 60-120s to detect that then it means
adjusting could take long also. Also, having opportunities to mark
"frequently" might be good, but has a cost for the network elements;
would like to limit endpoints to some timer as well. Two elements could
give different advice if elements don't mark every packet.
Brian: clarifying whether all of the protocol behavior is keyed off this
time constant?
Mirja: no
Martin: example 10Gbps for 3s and then change to kbps ... if the app
bursted too much, it can't comply.
Mirja: it is helpful to have the new information and use it instead of
the old. Don't think these times are tied in reality or need to be.
Don't think it should be phrased in this way.
Marcus: agree that any network can do what they want. would like to
define a midpoint or compromise; some elements could use a larger number
and some apps a smaller number. Consequences of making particular
choices can then be understood.
Mirja: not sure which is right, but we should definitely have a value.
wording is not right in the PR now though since nobody will use the same
value, or it's not enforceable that everyone does so.
Marcus: thinks there is value in some strong language
Mirja: but it's not a fact (brian encouraged sending a PR)
Tianji: it could be a minimum. example for some 5QI values 2000ms is
used.
Marcus: this is saying the one measuring conformance is committing to
this window.
Gorry: has become confused. Talk offline
Mo: argues for 2 rates, to indicate peak/burst rate. every video has
those average + peak rates within the encoding
Marcus: worried about complexity to indicate multiple rates
brian: does anyone need this?
Sanjay: I opened this, and am happy if you just close it.
Tian Ji, 10 minutes
(compressed talk to 5 minutes due to time)
Described diagrams of how SCONE fits into 5G system architecture.
Sanjay Mishra, 10 minutes
(also compressed due to time)
The draft addresses how network operators are looking at how to apply
SCONE and fit it into the network.
Brian w/ chair hat: date of Nov. to send to IESG is probably wrong. this
doc is about things beyond the protocol, and could be informed by more
hackathon work around montreal meeting. Take time pressure off trying to
meet milestone. thinks it is on-track, but will do show of hands.
Who has read the latest draft?
2 yes
12 no
2 no opinion
Chairs, 5 minutes
will propose on list to continue frequent interims; 3 september
suggested and 8 october