Subject: [Stackevo] Next steps: Stack Evolution Program communication on traffic characterization

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Nov 2015 15:00:04 +0100

Greetings, all,

One of the topics of discussion at the program meeting in Yokohama was "what next after MaRNEW". There is some indication of urgency in getting something deployed (preferably yesterday) to deal with the impact of encryption on traffic classification in some of these networks. While getting something done right is IMO by far more important than getting it done now, I think it would be useful to do things we know are useful now.

(1) Organization of a non WG forming BoF in Buenos Aires on some subset of the problem -- a bit more focused on the particulars of the MaRNEW space than the larger SPUD BoF in Dallas... I'm not exactly certain how to scope this to make sure it's a productive discussion, but I note we have more than sufficient time before BoF deadline for B-A to get this right.

(2) Issuance of a statement to this effect to this effect, which should also point out constraints we think we can agree about on the space of possible solutions here. This could be a Stack Evolution Program correspondence to the IAB and to other relevant organizations. Here's a first draft of some text here:

As an outcome of the workshop on Managing Radio Networks in an Encrypted World (MaRNEW) in Atlanta in September 2015, the Internet Architecture Board (IAB) IP Stack Evolution Program understands that the accelerating deployment of encryption is causing pain for mobile operators due to (1) requirements for traffic classification imposed by the architecture of mobile networks; and (2) the common application of Deep Packet Inspection (DPI)-based techniques, made impossible by encryption, to perform this classification.

There is ongoing work within the Program to address this issue, by replacing the implicit cooperation represented by DPI with facilities for explicit cooperation. We plan to hold meetings addressing focused aspects of explicit cooperation at the upcoming IETF meeting in Buenos Aires in April 2016. We can, however, articulate one architectural principle now to guide any further work in this space:

The characterization for the purposes of determining network treatment is best done in terms of network-layer rather than application-layer semantics. For example, instead of tagging a traffic flow as "H.323-encoded 4K broadcast video", the flow should be characterized in terms of its bandwidth and latency requirements and jitter and loss tolerance. Characterization in network-layer terms makes implementation of appropriate network- and link-layer treatment more straightforward, as well as removing irrelevant and potentially privacy-sensitive information from the metadata stream.

On behalf of the IAB IP Stack Evolution Program,

Brian Trammell, as Program Lead

Thoughts? Thanks, cheers,

Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Nov 2015 14:54:08 -0500

I know that we want programs to do more without full IAB voting, but I think that this is an example where the whole IAB will add value.  This statement really involves the StackEvo and the PrivSec programs.  Cross-program review is important here.

Editorial changes are suggested below ...

> 
> As an outcome of the workshop on Managing Radio Networks in an Encrypted World (MaRNEW) in Atlanta in September 2015, the Internet Architecture Board (IAB) understands that the increased use of encryption is causing pain for some mobile operators due to (1) requirements for traffic classification imposed by the architecture of mobile networks; and (2) the fact that encryption prevents the use of deep packet inspection (DPI) for this classification.
> 
> There is ongoing work within the IAB Stack Evolution Program to address this issue, by replacing the implicit cooperation represented by DPI with facilities for explicit cooperation. We plan to hold meetings addressing focused aspects of explicit cooperation at IETF 95 in Buenos Aires in April 2016. We can, however, articulate one architectural principle now to guide any further work in this space:
> 
> On behalf of the IAB,
> Brian Trammell, IAB Stack Evolution Program Lead

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Nov 2015 11:52:55 +0100

hi Russ,

> On 20 Nov 2015, at 20:54, Russ Housley <[email-masked]> wrote:
> 

This is a really good point -- so let's do that then. Copying privsec@.

privsec folks: this is a draft of an IAB communication to whomever it may concern in the mobile space (GSMA, 3GPP) pointing out that there is ongoing work on replacing DPI with something endpoint-cooperative and non-odious that works in the mobile space, but that there are already things that we know we don't want to do, and would advise anyone else not to do if they're engineering a solution in a panic. please have at it. :) If this  is something we'd want to come out of both programs, I'd suggest it be signed by both.

> Editorial changes are suggested below ...

All of these are good, thanks! So, the current text is:

On behalf of the IAB,

Brian Trammell, IAB Stack Evolution Program Lead
Ted Hardie, IAB Privacy and Security Program Lead

Thanks, cheers,

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Nov 2015 04:23:35 -0800

On Mon, Nov 23, 2015 at 2:52 AM, Brian Trammell <[email-masked]> wrote:

> > I know that we want programs to do more without full IAB voting, but I
> think that this is an example where the whole IAB will add value.  This
> statement really involves the StackEvo and the PrivSec programs.
> Cross-program review is important here.
>
> privsec folks: this is a draft of an IAB communication to whomever it may
> concern in the mobile space (GSMA, 3GPP) pointing out that there is ongoing
> work on replacing DPI with something endpoint-cooperative and non-odious
> that works in the mobile space, but that there are already things that we
> know we don't want to do, and would advise anyone else not to do if they're
> engineering a solution in a panic. please have at it. :) If this  is
> something we'd want to come out of both programs, I'd suggest it be signed
> by both.
>
> As an outcome of the workshop on Managing Radio Networks in an Encrypted
> World (MaRNEW) in Atlanta in September 2015, the Internet Architecture
> Board (IAB) understands that the increased use of encryption is causing
> pain for some mobile operators due to (1) requirements for traffic
> classification imposed by the architecture of mobile networks; and (2) the
> fact that encryption prevents the use of deep packet inspection (DPI) for
> this classification.
>
> There is ongoing work within the IAB Stack Evolution Program to address
> this issue, by replacing the implicit cooperation represented by DPI with
> facilities for explicit cooperation.

It's not clear to me how true this actually is. I appreciate that this is
something
that some people *want* to do, but it also seems to me that there is wide
recognition
that it has considerable downsides. Is there in fact any kind of consensus
that
this is something that we should *do*, a opposed to explore?

-Ekr

We plan to hold meetings addressing focused aspects of explicit cooperation
> at IETF 95 in Buenos Aires in April 2016. We can, however, articulate one
> architectural principle now to guide any further work in this space:
>
> The characterization for the purposes of determining network treatment is
> best done in terms of network-layer rather than application-layer
> semantics. For example, instead of tagging a traffic flow as "H.323-encoded
> 4K broadcast video", the flow should be characterized in terms of its
> bandwidth and latency requirements and jitter and loss tolerance.
> Characterization in network-layer terms makes implementation of appropriate
> network- and link-layer treatment more straightforward, as well as removing
> irrelevant and potentially privacy-sensitive information from the metadata
> stream.
>
> On behalf of the IAB,
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Nov 2015 14:04:49 +0100

Hi,

On 11/23/15 1:23 PM, Eric Rescorla wrote:
> > There is ongoing work within the IAB Stack Evolution Program to >
address this issue, by replacing the implicit cooperation represented >
by DPI with facilities for explicit cooperation. > > > It's not clear to
me how true this actually is. I appreciate that > this is something that
some people *want* to do, but it also seems to > me that there is wide
recognition that it has considerable downsides. > Is there in fact any
kind of consensus that this is something that we > should *do*, a
opposed to explore? >

+1. 

It might be fun to enumerate those downsides and see if they can
reasonably be overcome.  Two other points:

1.  The message does not really explain how people can participate in
discussions.  Presumably you want to get farther along before BA.

2.  Based on the above comment the following statement may require some

> The characterization for the purposes of determining network treatment is best done in terms of network-layer rather than application-layer semantics. For example, instead of tagging a traffic flow…

To be minimalist, let me suggest dropping the word "irrelevant".  It may
be very relevant, both to transport as well as, say, implementation
cybersecurity (to name but another example).

Eliot

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Nov 2015 15:56:11 +0100

Sent from my iPhone

> On 23 Nov 2015, at 12:24, Stephen Farrell <[email-masked]> wrote:
> 
> 
> From a privacy point of view, the term co-operation might not
> be so good, if it is used to imply that a person has "consented"
> to co-operate with something. I'm not sure what term might be
> better though.

How about "explicit" or "direct"... In saying "cooperative" here I'm looking primarily for a contrast to the way things are done now ("we'll look at anything we please, and bake that fact into the design, because we can") or the looming collapse of communication implied by an escalation over encryption ("okay we'll mitm you", "fine I'll apply [your favorite web-pki mitm fix", "fine we'll block or degrade stuff we can't mitm")...

> Or perhaps it'd be better to be explicit that
> what you're talking about basically never involves a person, but
> only involves bits of network stack code interacting with one
> another.

That's a very good point. Yeah, we should make that clearer anyway.

Cheers B

> 
> S.
> 
>> On 23/11/15 10:52, Brian Trammell wrote:
>> hi Russ,
>> 
>> 
>> Privsec-program mailing list
>> [email-masked]
>> https://www.iab.org/mailman/listinfo/privsec-program
> 
> Privsec-program mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/privsec-program

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Nov 2015 16:03:12 +0100

Sent from my iPhone

> On 23 Nov 2015, at 13:23, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> There is ongoing work within the IAB Stack Evolution Program to address this issue, by replacing the implicit cooperation represented by DPI with facilities for explicit cooperation.
> 
> It's not clear to me how true this actually is. I appreciate that this is something
> that some people *want* to do, but it also seems to me that there is wide recognition
> that it has considerable downsides. Is there in fact any kind of consensus that

No, no consensus. 

I believe the sense of the room at the stackevo meeting in Yokohama was that there is some danger that the amount of pain some operators are in (based on assumptions of plaintext baked kind of deeply into how they schedule radio usage) may lead them to apply fundamentally unhelpful fixes in a panic, that there is interest in exploring this in some subset of the program, that that exploration will probably not happen quickly enough for those who are in the most pain, that we do not want to do architecture with guns to our heads, but we should try to put something very specific in this space on the agenda for BA.

We should probably have some more concrete idea what that is before this goes out, and then this language can focus on that.

Cheers, B

> -Ekr
> 
>> We plan to hold meetings addressing focused aspects of explicit cooperation at IETF 95 in Buenos Aires in April 2016. We can, however, articulate one architectural principle now to guide any further work in this space:
>>

---

From: Dave Thaler <[email-masked]>
Date: Mon, 23 Nov 2015 17:00:47 +0000

EKR wrote:
>> […]
>>As an outcome of the workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
>> in Atlanta in September 2015, the Internet Architecture Board (IAB) understands that the increased
>> use of encryption is causing pain for some mobile operators due to (1) requirements for traffic
>> classification imposed by the architecture of mobile networks; and (2) the fact that encryption
>> prevents the use of deep packet inspection (DPI) for this classification.
>>
>> There is ongoing work within the IAB Stack Evolution Program to address this issue, by replacing
>>  the implicit cooperation represented by DPI with facilities for explicit cooperation.
>

Right, there is no such consensus, so I don’t think this is a good wording as is.
"address" and "replacing" both imply *do*.

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Nov 2015 11:24:48 +0000

better though. Or perhaps it'd be better to be explicit that

S.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Nov 2015 20:39:17 +0100

Sent from my iPhone

> On 23 Nov 2015, at 14:04, Eliot Lear <[email-masked]> wrote:
> 
> Hi,
> 
>> There is ongoing work within the IAB Stack Evolution Program to
>> address this issue, by replacing the implicit cooperation represented
>> by DPI with facilities for explicit cooperation.
>> 
>> 
>> It's not clear to me how true this actually is. I appreciate that
>> this is something that some people *want* to do, but it also seems to
>> me that there is wide recognition that it has considerable downsides.
>> Is there in fact any kind of consensus that this is something that we
>> should *do*, a opposed to explore?
>> 
> 
> +1.
> 
> It might be fun to enumerate those downsides and see if they can reasonably be overcome.

+1

> Two other points:
> 
> 1.  The message does not really explain how people can participate in discussions.  Presumably you want to get farther along before BA.

I think we want to get some idea about the scope of the session in BA before this goes out. I'd like to shoot for end of the year if possible.

> 2.  Based on the above comment the following statement may require some editing:
> 
> To be minimalist, let me suggest dropping the word "irrelevant".  It may be very relevant, both to transport as well as, say, implementation cybersecurity (to name but another example).

So this gets to the crux of the matter: there is a always a risk-utility tradeoff here, and the evaluation of utility is specific to the task. Legal intercept, certain security monitoring techniques, tools trying to audit applications' radiation of private data all require access to content, of course, so not only is all metadata relevant, all data is, too. Most tasks that have something to do with the popularity of content (advertising and distribution) at least need content identity.

But for the task of effectively managing transport-layer interactions (and assumptions the link layer makes about what it can know about the transport layer, which is what we're talking about here), I'm going to push back on this. The transport layer needs no semantic information about the content whatsoever. All it needs to know are how fast the packets are going to come, and how relatively bad it is to delay or drop them. Extra semantics about the application add risk for no additional utility here. Identifying these by underlying content type ("YouTube video", for example, is one almost universal identifier coming out of current DPI systems for traffic management as I understand it) is (1) an artifact of the implementation used to classify the traffic and (2) deceptively human-readable but (3) doesn't actually tell the network elements what is expected of them.

Cheers, B

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Nov 2015 21:04:53 +0100

Hi Brian,

Thanks for your response.  I'm particularly impressed with your
extensive elaboration on an iPhone ;-)  And I feel especially bad about
that given what I'll say below.

> So this gets to the crux of the matter: there is a always a risk-utility tradeoff here, and the evaluation of utility is specific to the task. Legal intercept, certain security monitoring technique…

Yes.

> But for the task of effectively managing transport-layer interactions (and assumptions the link layer makes about what it can know about the transport layer, which is what we're talking about here), I'm going to push back on this. The transport layer needs no semantic information about the content whatsoever.

I mostly agree.  The corner case has to do with codecs, which are weird
things (at least to me) that have very transporty aspects.  And that was
the example at hand.  But I don't have the context about MarNEW to know
whether or not the other stuff above is or is not relevant.

>  All it needs to know are how fast the packets are going to come, and how relatively bad it is to delay or drop them. Extra semantics about the application add risk for no additional utility here. Identifying these by underlying content type ("YouTube video", for example, is one almost universal identifier coming out of current DPI systems for traffic management as I understand it) is (1) an artifact of the implementation used to classify the traffic and (2) deceptively human-readable but (3) doesn't actually tell the network elements what is expected of them.
>
This holds true so long as the behaviors are optimal for codecs, that is
fine.  I can't answer that question; perhaps others can.  I know that Al
Norton has done a LOT of work on that...

I also want to point out that something can be relevant and wrongheaded ;-)

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Nov 2015 12:30:21 -0800

On Mon, Nov 23, 2015 at 11:39 AM, Brian Trammell <[email-masked]> wrote:

>
>
> So this gets to the crux of the matter: there is a always a risk-utility
> tradeoff here, and the evaluation of utility is specific to the task. Legal
> intercept, certain security monitoring techniques, tools trying to audit
> applications' radiation of private data all require access to content, of
> course, so not only is all metadata relevant, all data is, too. Most tasks
> that have something to do with the popularity of content (advertising and
> distribution) at least need content identity.
>
> But for the task of effectively managing transport-layer interactions (and
> assumptions the link layer makes about what it can know about the transport
> layer, which is what we're talking about here), I'm going to push back on
> this.
>

​I wanted to reinforce this​, because we have seen a fair few cases where
operators which do both radio network management and other services
conflate what they need for the other services with what they need for the
radio network management.  If operator X runs an anti-virus service on its
network, they may well see the requirement for content access as "part of
what I need to run my network".  Only if we are scrupulous in making the
distinction between those services and the radio network itself, though,
are we going to be able to keep this both privacy friendly and tractable as
a problem.

regards,

Ted

(I am not on Brian's iPhone)

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Nov 2015 23:51:08 +0000

On Monday, November 23, 2015 12:53 AM, Brian Trammell wrote:
> ...
> There is ongoing work within the IAB Stack Evolution Program to address this
> issue, by replacing the implicit cooperation represented by DPI with facilities
> for explicit cooperation. 

Good thing I was not having breakfast when reading the blurb about "implicit cooperation." Seriously? Implicit cooperation as another name for "unilateral action without asking anyone their advice?" A more neutral rewrite might be:

...replacing the information obtained through DPI with facilities for explicit cooperation.

And yes, I too think that we are on the right track if we focus on "effectively managing transport-layer interactions," by opposition to various "added value" services.

By the way, if there is a consensus, it probably starts with Jana's suggestions in Atlanta. Start by checking what can be done with state of the art AQM, without any additional information. Once that is evaluated, consider adding 1 bit of information in the packets. Etc.

-- Christian Huitema

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Nov 2015 07:21:47 +0100

hi Eliot,

> On 23 Nov 2015, at 21:04, Eliot Lear <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Thanks for your response.  I'm particularly impressed with your extensive elaboration on an iPhone ;-)  And I feel especially bad about that given what I'll say below.
> 
> I mostly agree.  The corner case has to do with codecs, which are weird things (at least to me) that have very transporty aspects.

Okay, that's a valid point.

> And that was the example at hand.

Yep... it was a bad one, although in many applications, there's still a component between the encoder and the sender that can change the shape of the traffic (think adaptive bitrate streaming). For interactive video, the codec *does* need be closer to the wire for good results.

Video service ("this is YouTube") is a more illustrative example of the type of less relevant metadata I'm thinking of here. Classification of this type conflates the transport characteristics ("traffic with whatever shape YouTube has this year") with others ("a website with rlarge amounts of user-generated content")

>   But I don't have the context about MarNEW to know whether or not the other stuff above is or is not relevant.
> 
> This holds true so long as the behaviors are optimal for codecs, that is fine.  I can't answer that question; perhaps others can.  I know that Al Norton has done a LOT of work on that...

I'll ping Al.

> I also want to point out that something can be relevant and wrongheaded ;-)

Indeed. What I'd like to do here is use the fact that encryption will wreck the current way of doing things issue a challenge to be less wrongheaded when designing the next one.

Thanks, cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Nov 2015 07:21:48 +0100

> On 24 Nov 2015, at 00:51, Christian Huitema <[email-masked]> wrote:
> 
> Good thing I was not having breakfast when reading the blurb about "implicit cooperation." Seriously? Implicit cooperation as another name for "unilateral action without asking anyone their advice?"

I had less pernicious things in mind with this phrasing (TCP re-pacing for LTE, an arrangement in which arguably everyone wins as long as they're okay using TCP forever). But yes, this phrasing may be too diplomatic.

> A more neutral rewrite might be:
> 

I would generalize it: "replacing the information obtained through traffic inspection and analysis" (with other caveats about ensuring the statement accurately reflects the present lack of consensus in this area).

> By the way, if there is a consensus, it probably starts with Jana's suggestions in Atlanta. Start by checking what can be done with state of the art AQM, without any additional information. Once th…

I think this is a very good way forward, with the caveat that there is already present work in AQM that does implicit traffic classification to assign traffic to different queues (conflating ECT(0) marking with a request for a particular type of service)...

Thanks, cheers,

Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Nov 2015 08:19:13 +0100

Hi Brian,

> Indeed. What I'd like to do here is use the fact that encryption will wreck the current way of doing things issue a challenge to be less wrongheaded when designing the next one.

Right.  The fundamental issue is that starting point.  It could be one
of a number of areas, such as:

 1. With the increased adoption of encryption, we need to find new ways
    to address certain challenges (and mention what they are, and what
    the plan is for each (which might include saying something like "not
    there yet" for some); or
 2. With the increased adoption of encryption, one of the issues we are
    addressing relates to transport, and we are focusing down on that.

To me, right now the statement reads as (2).  One reason to do that is,
as Ted writes, to not bite off too much at once.  But at least a nod
that these others issues are interrelated and need to be addressed seems
helpful to show that they haven't been lost, and (IMHO) also shows that
the IAB is thinking broadly.  It is also true to the statement the board
made last November, in highlighting some of those issues.  It also is a
reason for the IAB to work on this sort of broad problem, as opposed to
the IETF, thus demonstrating IAB value.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Nov 2015 05:34:09 -0800

On Mon, Nov 23, 2015 at 11:19 PM, Eliot Lear <[email-masked]> wrote:

> Right.  The fundamental issue is that starting point.  It could be one of
> a number of areas, such as:
>
>    to address certain challenges (and mention what they are, and what the plan
>    is for each (which might include saying something like "not there yet" for
>    some); or
>
>
Hmm... The set of challenges that operators have claimed seems to include
things that we actually want to stop. It may well be the case that once we
have
done the analysis the set of "valid" challenges is non-empty, but I don't
think
that's clear yet.

-Ekr

>    1.
> To me, right now the statement reads as (2).  One reason to do that is, as
> Ted writes, to not bite off too much at once.  But at least a nod that
> these others issues are interrelated and need to be addressed seems helpful
> to show that they haven't been lost, and (IMHO) also shows that the IAB is
> thinking broadly.  It is also true to the statement the board made last
> November, in highlighting some of those issues.  It also is a reason for
> the IAB to work on this sort of broad problem, as opposed to the IETF, thus
> demonstrating IAB value.
>
> Eliot
>
>

---

From: Aaron Falk <[email-masked]>
Date: Tue, 24 Nov 2015 11:41:25 -0500

A slightly meta point, based on the workshop and the discussion above is
that we are pretty far from discussing a concrete proposal and I fear
trying to make headway in a BoF slot will be challenging.  The risk is that
we simply restate incompatible points of view without time to forge a
consensus or, worse, exclude a stakeholder community completely in the
interests of making progress.

Perhaps a half-day or full-day meeting before the IETF (with prep-work to
put some data, requirements, and proposals on the table) would be more
fruitful.  We might even schedule a short BoF slot for an outbrief and
discussion if there are slots available on the agenda.

--aaron

On Tue, Nov 24, 2015 at 8:34 AM, Eric Rescorla <[email-masked]> wrote:

>>    1. With the increased adoption of encryption, we need to find new
>>    ways to address certain challenges (and mention what they are, and what the
>>    plan is for each (which might include saying something like "not there yet"
>>    for some); or
>>
>>
>>    2. With the increased adoption of encryption, one of the issues we
>>    are addressing relates to transport, and we are focusing down on that.
>>
>> as Ted writes, to not bite off too much at once.  But at least a nod that

---

From: Natasha Rooney <[email-masked]>
Date: Fri, 27 Nov 2015 09:55:04 +0000

Catching up with these mails...

On Nov 24, 2015, at 8:51 AM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

I have this as a "next steps" for MaRNEW, but still unsure of how to properly proceed. Below is the suggested route forward from the short MaRNEW meeting at 94. I’m not jumping on this right now, but would appreciate some support in working on this in the new year. I am attacking the opcos too!

Zero / One bit for latency bandwidth tradeoff
A reminder for all: this idea looks at removing all network management tools from a network, test, then add one bit for latency / bandwidth tradeoff (e.g. video or not video, or latency or bandwidth, drop vs queue) and test again to see if there is an improvement. Possible expand to other bits, and then find the optimum combination taking privacy into account. The group agreed that testing this is necessary, and this work is perfect fit for university or lab based study. I will investigate bringing it into the GSMA proposal, but it probably it a better fit to fund some university research on this outside of the GSMA and IETF work existing.

ACTION (ALL): I will start investigating this in January. If you have some ideas of how we could fund / find a research body to work on this let me know.

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Natasha Rooney <[email-masked]>
Date: Fri, 27 Nov 2015 10:01:02 +0000

On Nov 24, 2015, at 10:34 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

Hmm... The set of challenges that operators have claimed seems to include
things that we actually want to stop. It may well be the case that once we have
done the analysis the set of "valid" challenges is non-empty, but I don't think
that's clear yet.

The statements in MaRNEW clear this up though right? See the scope from MaRNEW:
https://docs.google.com/presentation/d/1enzQUecrfmCGb20IueA6D8j8OwHTMVFzpkUasQy4Dd4/edit#slide=id.ge12e9fe5e_1_0

We identify that the regulation / policy stuff is out, and we’re not having anything to do with it. Can the IAB statement say the same in some way? Something like…

"There is ongoing work within the IAB Stack Evolution Program to address [issues related specifically to network management], …"

You could link to something which defines it more, we did this on the MaRNEW site (because, as with everything, telecoms and internet labels everything differently! Network Management to us is actually management for technological reasons, QoS is the evil thing, and in MaRNEW we called network management "bandwidth optimisation").
https://www.iab.org/activities/workshops/marnew/

---

From: Brian Trammell <[email-masked]>
Date: Mon, 30 Nov 2015 15:49:19 +0100

Greetings, all,

Picking up this thread again...

We discussed this on the IAB call last Wednesday, and I think there's a possible ways forward for a useful non-WG-forming BoF meeting before/in Buenos Aires. Here we'd want to discussing the "zero/one bit" approach to traffic characterization and signaling in mobile networks (I'd already sign up David for explaining how DSCP applies here :) ). This probably needs a fair amount of preparation in order to scope properly, or we end up having the SPUD BoF again.

I also think there's something to be gained by asking someone from GSMA to come talk about what traffic classification for radio management means, for a broader IETF audience.

So if this seems like a reasonable scope, considering feedback to date in this thread on the proposed statement, I *think* what we have looks like this (apologies if I'm missing something here...):

This is a hard problem. There is ongoing work within the IAB Stack Evolution Program to investigate the replacement the information obtained through traffic inspection and analysis with explicit approaches for endpoint-middlebox cooperation, and discussion of these subject continues on the [email-masked] list. In addition, we plan to meet at IETF 95 in Buenos Aires in April 2016 to address a focused set of questions about this problem: what is the minimal amount of information that can be given to radio networks classification and traffic management processes? Is it possible to use existing approaches (e.g. state-of-the-art active queue management (AQM)) to partially replace DPI? How can these minimal signaling requirements be best met within the existing, deployed Internet architecture?

At this time, we can, however, articulate one architectural principle now to guide any further work in this space:

The characterization for the purposes of determining network treatment is best done in terms of network-layer rather than application-layer semantics. For example, instead of tagging a traffic flow as "YouTube", the flow should be characterized in terms of its bandwidth and latency requirements and jitter and loss tolerance. Characterization in network-layer terms makes implementation of appropriate network- and link-layer treatment more straightforward, as well as removing potentially privacy-sensitive information from the metadata stream that is irrelevant to traffic management.

On behalf of the IAB,

Let the arrows fly, thanks, cheers,

Brian

> On 24 Nov 2015, at 07:21, Brian Trammell <[email-masked]> wrote:
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Mon, 30 Nov 2015 19:04:10 +0000

> -----Original Message-----
> From: Stackevo [mailto:[email-masked]] On Behalf Of Brian
> Trammell
> Sent: Monday, November 30, 2015 6:49 AM
> To: Stackevo <[email-masked]>; [email-masked]
> Cc: IAB <[email-masked]>
> Subject: Re: [Stackevo] [IAB] [Privsec-program] Next steps: Stack Evolution
> Program communication on traffic characterization
> 
> Greetings, all,
> 
> We discussed this on the IAB call last Wednesday, and I think there's a possible
> ways forward for a useful non-WG-forming BoF meeting before/in Buenos
> Aires. Here we'd want to discussing the "zero/one bit" approach to traffic
> characterization and signaling in mobile networks (I'd already sign up David for
> explaining how DSCP applies here :) ). This probably needs a fair amount of
> preparation in order to scope properly, or we end up having the SPUD BoF
> again.
> 
> I also think there's something to be gained by asking someone from GSMA to
> come talk about what traffic classification for radio management means, for a
> broader IETF audience.
> 
> So if this seems like a reasonable scope, considering feedback to date in this
> thread on the proposed statement, I *think* what we have looks like this
> (apologies if I'm missing something here...):
> 
> 
> Board (IAB) understands that the increased use of encryption is causing pain for
> some mobile operators due to (1) requirements for traffic classification
> imposed by the architecture of mobile networks; and (2) the fact that
> encryption prevents the use of deep packet inspection (DPI) for this
> classification.
> 
> This is a hard problem. There is ongoing work within the IAB Stack Evolution
> Program to investigate the replacement the information obtained through

Can't parse "the replacement the"
Did you mean "the replacement of"?

> traffic inspection and analysis with explicit approaches for endpoint-middlebox
> cooperation, and discussion of these subject continues on the stackevo-
> [email-masked] list. In addition, we plan to meet at IETF 95 in Buenos Aires in
> April 2016 to address a focused set of questions about this problem: what is the
> minimal amount of information that can be given to radio networks
> classification and traffic management processes? 

Above wording might be ok as is, but the wording does seem odd.  E.g.
Is it "what's the minimal amount that can be given to any (including new) processes?"
If so then answer is probably "zero, but you'll lose some scenarios".
Is it "what's the minimal amount that can be given to today's processes?"
If so then the answer is probably "today's tools depend on full DPI".
Or is it "How could you change today's processes/tools to require less information
and still meet the same scenarios?"
Or is it "How could you reduce the scenarios to something less, while not losing too
much money?"
Or is it something else?   Again, I'm just not sure what question you're really trying
to ask for Buenos Aires.

> Is it possible to use existing
> approaches (e.g. state-of-the-art active queue management (AQM)) to partially
> replace DPI? How can these minimal signaling requirements be best met within
> the existing, deployed Internet architecture?
> 
> The characterization for the purposes of determining network treatment is best
> done in terms of network-layer rather than application-layer semantics. For
> example, instead of tagging a traffic flow as "YouTube", the flow should be
> characterized in terms of its bandwidth and latency requirements and jitter and
> loss tolerance. 

Are you sure the mobile operators would agree with that?  My understanding is
that some of them want to preference specific sites (like youtube or Netflix) for
business reasons (e.g., the site subsidizes costs to reach it, and so pays the ISP).  Please
let me know if that's incorrect.  Now you might be able to tag a traffic flow by L3
destination to achieve some of that, unless the L3 destination address is shared
(e.g., via a CDN) with other things that they don't get revenue from.

> Characterization in network-layer terms makes implementation
> of appropriate network- and link-layer treatment more straightforward, as well
> as removing potentially privacy-sensitive information from the metadata
> stream that is irrelevant to traffic management.
> 
> On behalf of the IAB,
> 
> Brian Trammell, IAB Stack Evolution Program Lead Ted Hardie, IAB Privacy and
> Security Program Lead
> 
> 
> >>> address this issue, by replacing the implicit cooperation
> >>> represented by DPI with facilities for explicit cooperation.
> >>
> >> Good thing I was not having breakfast when reading the blurb about
> "implicit cooperation." Seriously? Implicit cooperation as another name for
> "unilateral action without asking anyone their advice?"
> >
> > I had less pernicious things in mind with this phrasing (TCP re-pacing for LTE,
> an arrangement in which arguably everyone wins as long as they're okay using
> TCP forever). But yes, this phrasing may be too diplomatic.
> >
> > I would generalize it: "replacing the information obtained through traffic
> inspection and analysis" (with other caveats about ensuring the statement
> accurately reflects the present lack of consensus in this area).
> >
> >>
> >> And yes, I too think that we are on the right track if we focus on "effectively
> managing transport-layer interactions," by opposition to various "added value"
> services.
> >>
> >> By the way, if there is a consensus, it probably starts with Jana's suggestions
> in Atlanta. Start by checking what can be done with state of the art AQM,
> without any additional information. Once that is evaluated, consider adding 1
> bit of information in the packets. Etc.
> >
> > I think this is a very good way forward, with the caveat that there is already
> present work in AQM that does implicit traffic classification to assign traffic to
> different queues (conflating ECT(0) marking with a request for a particular type
> of service)...
> >
> > Thanks, cheers,
> >
> > Brian
> >
> >> -- Christian Huitema
> >>
> >>
> >>
> >>
> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
> >>
> iab.org%2fmailman%2flistinfo%2fstackevo&data=01%7c01%7cdthaler%40micr
> >>
> osoft.com%7ce6afd39099b643427d1e08d2f9957308%7c72f988bf86f141af91ab
> 2d
> >>
> 7cd011db47%7c1&sdata=3ZwnOmIklJt4IhYS6gJRhiPL55gGdFnr0IUN9dm1Eso%3
> d
> >

---

From: Ted Hardie <[email-masked]>
Date: Mon, 30 Nov 2015 11:18:38 -0800

> (e.g., via a CDN) with other things that they don't get revenue from.

​I think we want to be careful describing this, but I also believe that at
least some mobile operators agreed with this.  What they are doing on the
radio resource side is looking at a flow to determine what channel bandwith
size and priority to assign; that's the bit where we believe replacing DPI
with much lower amounts of information will continue to work (and may be
cheaper).

They may be doing other things with flow information, including zero
rating, but that's a billing function rather than a radio resource
management function; doing that with the same system may be a convenience,
but it isn't a necessity.  As you note, there are other ways of tackling
that.

Also note that any system falling under network neutrality rules, they
should not be applying network-level preferences based on destination, and
the ability to defend their behavior based on assertions that this was the
cause of specific speed differences might be a benefit.

regards,

Ted

---

From: Dave Thaler <[email-masked]>
Date: Mon, 30 Nov 2015 19:24:36 +0000

Right, and to date, the IAB has carefully avoided taking any position on net neutrality policy issues.
I’m not sure we’d want to wade into that now, and the proposed “best done in terms of”
statement wording could be read as starting to step into that space.   Hence my question.

Dave

From: Ted Hardie [mailto:[email-masked]]
Sent: Monday, November 30, 2015 11:19 AM
To: Dave Thaler <[email-masked]>
Cc: Brian Trammell <[email-masked]>; Stackevo <[email-masked]>; [email-masked]; IAB <[email-masked]>
Subject: Re: [Stackevo] [IAB] [Privsec-program] Next steps: Stack Evolution Program communication on traffic characterization

​I think we want to be careful describing this, but I also believe that at least some mobile operators agreed with this.  What they are doing on the radio resource side is looking at a flow to determine what channel bandwith size and priority to assign; that's the bit where we believe replacing DPI with much lower amounts of information will continue to work (and may be cheaper).
They may be doing other things with flow information, including zero rating, but that's a billing function rather than a radio resource management function; doing that with the same system may be a convenience, but it isn't a necessity.  As you note, there are other ways of tackling that.

Also note that any system falling under network neutrality rules, they should not be applying network-level preferences based on destination, and the ability to defend their behavior based on assertions that this was the cause of specific speed differences might be a benefit.
regards,
Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 30 Nov 2015 11:31:11 -0800

> statement wording could be read as starting to step into that space.

​Well, I think we have waded into the privacy/confidentiality discussion.
One consequence of that is we are not just recommending encryption, but
recommending ​that you don't augment the encrypted data with anything that
is equally corrosive to privacy.  So, the question is:  if you're not using
DPI to assign network treatment, what's the simplest thing you can replace
it with?  The answer we've come to is "requests for network treatment, if
the base network treatment is not correct" (note that could be for
scavenger class treatment, rather than express treatment).  The zero-bit
version addendum is "and the base network treament is going to be right
almost all the time".

I don't think we're wading into network neutrality per se here, but I'd be
happy to consider other descriptions of why we're arguing that revealing
DPI-equivalent stuff in metadata isn't necessary or wise.

regards,

Ted

> Dave
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Monday, November 30, 2015 11:19 AM
> *To:* Dave Thaler <[email-masked]>
> *Cc:* Brian Trammell <[email-masked]>; Stackevo <[email-masked]>;
> [email-masked]; IAB <[email-masked]>
> *Subject:* Re: [Stackevo] [IAB] [Privsec-program] Next steps: Stack
> Evolution Program communication on traffic characterization
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 30 Nov 2015 11:58:25 -0800

> Or is it something else?   Again, I'm just not sure what question you're

I have similar thoughts. Specifically, traffic classification is a
solution, not a problem. Before moving forward on articulating solution
spaces ("the minimal amount of information required for traffic
classification"), I think we need to articulate the problem(s) we're
seeking to solve. From what I've heard from operators, their stated
fundamental problem is resource scheduling, and they use content
classification to solve that problem. I'd love to be proven wrong, but it's
still not clear to me that content classification is necessary for
scheduling decisions. What other problem are we trying to solve?

It's not yet clear to me what the well-articulated problem is for which we
would ask the IETF to engineer a solution.

- jana

> > At this time, we can, however, articulate one architectural principle
> now to
> > guide any further work in this space:
> >
> > >> ...replacing the information obtained through DPI with facilities for
> explicit
> > cooperation.
> > >

---

From: Ted Hardie <[email-masked]>
Date: Mon, 30 Nov 2015 12:12:09 -0800

On Mon, Nov 30, 2015 at 11:58 AM, Jana Iyengar <[email-masked]> wrote:

> solution, not a problem.

​In the network architecture currently common to 3GPP, the adjustment in
radio resource allocation occurs after traffic classification.  The
classification is a architecturally a first step to setting up the network
for the user equipment.

If you changed your statement to "differential traffic classification",
you'd be closer, because it may be that setting up a common allocation per
flow with modern AQM works as well as setting up differential resources.
That's a test we can design and encourage folks to run.  We can then test
from there if small numbers of bits of further information helps with user
experience and network resource allocation, or not.

But we should be very careful in describing this, because just saying "drop
this step" doesn't work--you have to keep the step even if it always
returns the same value during the test, or you are changing the
architecture in advance of running the tests.

regards,

Ted

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Nov 2015 12:14:08 -0800

> scheduling decisions. What other problem are we trying to solve?

I couldn't agree more.

-Ekr

>> > >> ...replacing the information obtained through DPI with facilities
>> for explicit
>> > cooperation.
>> > >

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 1 Dec 2015 06:55:39 +0000

On Dec 1, 2015, at 4:58 AM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

I have similar thoughts. Specifically, traffic classification is a solution, not a problem. Before moving forward on articulating solution spaces ("the minimal amount of information required for traffic classification"), I think we need to articulate the problem(s) we're seeking to solve. From what I've heard from operators, their stated fundamental problem is resource scheduling, and they use content classification to solve that problem. I'd love to be proven wrong, but it's still not clear to me that content classification is necessary for scheduling decisions. What other problem are we trying to solve?

It's not yet clear to me what the well-articulated problem is for which we would ask the IETF to engineer a solution.

My interpretation on the question is actually two questions:

[1] "How could you change today's processes/tools to require less information and still meet the same scenarios?" and:
[2] Are tools even necessary to meet the same scenarios or can we just use sophisticated protocols.*

I think it’s important, however, to state what the "same scenarios" cover in this case. In IETF we are only interested in the bandwidth optimisation case. This is best detailed in the "Understanding “Bandwidth Optimization”" section of the MaRNEW site:
https://www.iab.org/activities/workshops/marnew/

In which case, network management for business reasons (including fast lanes and zero rating) is not included. Effectively the situations we are trying to prevent is blockages in the network when, for example, many people are trying to access high quality video and blocking other traffic from reaching a user’s device. The "scenarios" then are technical, or engineering-based. Not monetary based. I’m going to follow up with another email explaining some of the delicacies here (to stackevo).

I really hope this helps - shout if you need more info!

Natasha

* I know [2] is something we (as operators) should know, but this industry is horridly closed and often puts business before technical sense. I think many operators are in the case of thinking the expensive middleboxes in their network are doing good things and continue to push this to back up the expense they part with acquiring them. This is not tested so cannot be stated publicly, and this is something we will work on within the MaRNEW next steps.

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 1 Dec 2015 07:07:48 +0000

As promised here is the follow-up email to the discussion on network management within mobile operator networks! I like to classify network management into three categories to make conversations simpler (or confuse them more… let’s see!):

[1] Network Management for Business Reasons
This includes fast lanes and zero rating.

[2] Network Management for Policy Reasons
This includes censorship, and legal interception.

[3] Network Management for Technical Reasons
This includes preventing network blockages and sensible resource allocation.

In the IETF I understand (as does the GSMA operators who attend IETF) that we are tackling [3], and only [3]. Many of you know myself and a collection of others make it our place to discourage [1] and [2] within GSMA (I won’t discuss this here, but please speak to me about this separately if you wish).

Saying this, our industry is large and I know there are others who exist in GSMA member companies, and other operator IETF attendees, who do not agree with this and will push for [1] and [2] within IETF. IETF is open so of course they can attend to give these viewpoints. But [3] is the only focus for us (GSMA) and is reinforced strongly with respect to the work we are doing with MaRNEW and this proposed BOF / Bar-BOF.

You guys can use this classification if you wish. Also feel free to connect me with any operator attendee at IETF who may be expressing other views, it might be good to chat with them so they can better understand the industry position.

I hate my GSMA hat so I’ll take it off now!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
Tokyo, Japan

On Dec 1, 2015, at 5:12 AM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Nov 30, 2015 at 11:58 AM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

I have similar thoughts. Specifically, traffic classification is a solution, not a problem.

​In the network architecture currently common to 3GPP, the adjustment in radio resource allocation occurs after traffic classification.  The classification is a architecturally a first step to setting up the network for the user equipment.

If you changed your statement to "differential traffic classification", you'd be closer, because it may be that setting up a common allocation per flow with modern AQM works as well as setting up differential resources.  That's a test we can design and encourage folks to run.  We can then test from there if small numbers of bits of further information helps with user experience and network resource allocation, or not.

But we should be very careful in describing this, because just saying "drop this step" doesn't work--you have to keep the step even if it always returns the same value during the test, or you are changing the architecture in advance of running the tests.

regards,

Ted
_______________________________________________
Stackevo mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/stackevo