Subject: [Marnew] Marnew reflections

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Sep 2015 03:12:38 +0200

Dear all,

With a long flight, I've been having some time to think about MARNEW, 
and read some papers.
So here is a list of questions and reflections in preparation for the 
workshop.

- My first point is: what is specific to radio networks? 
Fluctuating/unknown bandwidth, limited cellular capacity, maybe more 
caching? IMO, the problem space is not specific to radio networks, 
specifically if we have QoE in mind. We can think of it as "Managing 
Networks in an Encrypted World". I would be happy to learn about the 
radio network specifics during the workshop.

- Clarifying question: Is this workshop focusing on encrypted web 
traffic only, or all traffic/applications encryption?

- IMO, there are three aspects to encryption:
1. As an end user, I want privacy
2. As an employee, I require privacy, but I also require the right QoE 
for my business applications
3. As an operator, I'm not interested to look at the unencrypted 
packets, but I need to manage the networks. Everybody blames the network 
(even if it's not the network, but the servers ... but that's a 
different story). One aspect to provide the right QoE/QoS has been DPI. 
With the increase of encryption, that will not be a solution any longer.

- In terms of mechanism to provide the right QoS/QoE, there are two ways:
1. the operator is able to deduce the information. This is the DPI 
story. With encryption, that will be a challenge as mentioned.
2. the end-user communicate its QoS requirements to the network. Ex: hey 
mister operator, treat this series of packets (and I won't tell the 
content) as real-time traffic.

- Here we have a series of questions wrt the end-user communicating its 
requirements to the network.
     - QoE/QoS per device, per user, per session, per flow, per 
applications? Per application I guess, potentially per flow.
     - Do the end users know what they need in terms of QoS parameters: 
delay, packet loss, delay variation? Not sure...
       Maybe the applications know, but won't they all the time require 
the best QoS
     - DSCP has not been used appropriately. Why would it work this 
time? We could link this to some dollars: hey mister operator, treat 
this series of packets as real-time traffic, and I will pay extra for 
this. However, a complex billing system is ... costly.

- All these problems were discussed part of Application Enabled 
Collaborative Network (AECON).
However, that BoF was not approved at IETF 90. See 
http://trac.tools.ietf.org/bof/trac/wiki/BofIETF90 and review the 
description. There are some similarities.

Regards, Benoit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Sep 2015 02:14:36 -0500

Hi, Benoit,

On Wed, Sep 23, 2015 at 8:12 PM, Benoit Claise <[email-masked]> wrote:

> Dear all,
>
> With a long flight, I've been having some time to think about MARNEW, and
> read some papers.

In the words of Bob Dylan, "I'm not sleepy, and there is no place I'm going
to ..." (https://www.youtube.com/watch?v=bH4SF7FrNzc1). So ...

> Networks in an Encrypted World". I would be happy to learn about the radio
> network specifics during the workshop.

It is my intention that we talk about this during the Transport session on
Friday. Perhaps that should have been scheduled earlier in the workshop (my
bad, if so).

But what you're saying is very consistent with the way my request for a
working group on "TCP over cellular" in something like 1997 morphed into
https://datatracker.ietf.org/wg/pilc/history/ in 1999 under (IIRC) Vern
Paxton and Scott Bradner as TSV ADs.

We already had a "TCP over satellite" working group, chaired by Aaron
Falk. Rather than do "TCP over foo" working groups until the end of time,
we focused on the resulting characteristics - at the time, low bandwidth,
long delays, high error rates, and assymetric paths. We've identified some
other problems since then (NATs, reordering during handoffs, and
bufferbloat), but the PILC characteristics are still a good start.

As an aside, Aaron and I were PILC co-chairs :-)

> - Clarifying question: Is this workshop focusing on encrypted web traffic
> only, or all traffic/applications encryption?
>
> 2. As an employee, I require privacy, but I also require the right QoE for
> my business applications
> 3. As an operator, I'm not interested to look at the unencrypted packets,
> but I need to manage the networks. Everybody blames the network (even if
> it's not the network, but the servers ... but that's a different story).
> One aspect to provide the right QoE/QoS has been DPI. With the increase of
> encryption, that will not be a solution any longer.
>
> 1. the operator is able to deduce the information. This is the DPI story.
> With encryption, that will be a challenge as mentioned.

Yes, exactly (IMO).

>       Maybe the applications know, but won't they all the time require the
> best QoS
>     - DSCP has not been used appropriately. Why would it work this time?
> We could link this to some dollars: hey mister operator, treat this series
> of packets as real-time traffic, and I will pay extra for this. However, a
> complex billing system is ... costly.
>

This has been a recurring converstion thst hasn't converged since before
PILC. I hope we can nail it down this time, at least better than we usually
do.

> Regards, Benoit

And thank you for an e-mail kickoff to get things started. You did good.

Spencer, as TSV AD

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Sep 2015 11:59:34 +0000

Marcus Ihlar will try to present the radio specific needs during the transport session at the extends time permits
Or we can have an offline transport discussion to go deeply

however Radio is also evolving and the needs will also consequently do
(i.e. there will be more bandwidth in the future but it will fluctuate more dramatically)

BR
Salvatore

From: Marnew [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: den 24 september 2015 03:15
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [Marnew] Marnew reflections

Hi, Benoit,

On Wed, Sep 23, 2015 at 8:12 PM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

With a long flight, I've been having some time to think about MARNEW, and read some papers.
So here is a list of questions and reflections in preparation for the workshop.

In the words of Bob Dylan, "I'm not sleepy, and there is no place I'm going to ..." (https://www.youtube.com/watch?v=bH4SF7FrNzc1). So ...

- My first point is: what is specific to radio networks? Fluctuating/unknown bandwidth, limited cellular capacity, maybe more caching? IMO, the problem space is not specific to radio networks, specifically if we have QoE in mind. We can think of it as "Managing Networks in an Encrypted World". I would be happy to learn about the radio network specifics during the workshop.

It is my intention that we talk about this during the Transport session on Friday. Perhaps that should have been scheduled earlier in the workshop (my bad, if so).

But what you're saying is very consistent with the way my request for a working group on "TCP over cellular" in something like 1997 morphed into https://datatracker.ietf.org/wg/pilc/history/ in 1999 under (IIRC) Vern Paxton and Scott Bradner as TSV ADs.

We already had a "TCP over satellite" working group, chaired by Aaron Falk. Rather than do "TCP over foo" working groups until the end of time, we focused on the resulting characteristics - at the time, low bandwidth, long delays, high error rates, and assymetric paths. We've identified some other problems since then (NATs, reordering during handoffs, and bufferbloat), but the PILC characteristics are still a good start.

- Clarifying question: Is this workshop focusing on encrypted web traffic only, or all traffic/applications encryption?

- IMO, there are three aspects to encryption:
1. As an end user, I want privacy
2. As an employee, I require privacy, but I also require the right QoE for my business applications
3. As an operator, I'm not interested to look at the unencrypted packets, but I need to manage the networks. Everybody blames the network (even if it's not the network, but the servers ... but that's a different story). One aspect to provide the right QoE/QoS has been DPI. With the increase of encryption, that will not be a solution any longer.

- In terms of mechanism to provide the right QoS/QoE, there are two ways:
1. the operator is able to deduce the information. This is the DPI story. With encryption, that will be a challenge as mentioned.
2. the end-user communicate its QoS requirements to the network. Ex: hey mister operator, treat this series of packets (and I won't tell the content) as real-time traffic.

Yes, exactly (IMO).

- Here we have a series of questions wrt the end-user communicating its requirements to the network.
    - QoE/QoS per device, per user, per session, per flow, per applications? Per application I guess, potentially per flow.
    - Do the end users know what they need in terms of QoS parameters: delay, packet loss, delay variation? Not sure...
      Maybe the applications know, but won't they all the time require the best QoS
    - DSCP has not been used appropriately. Why would it work this time? We could link this to some dollars: hey mister operator, treat this series of packets as real-time traffic, and I will pay extra for this. However, a complex billing system is ... costly.

- All these problems were discussed part of Application Enabled Collaborative Network (AECON).
However, that BoF was not approved at IETF 90. See http://trac.tools.ietf.org/bof/trac/wiki/BofIETF90 and review the description. There are some similarities.

This has been a recurring converstion thst hasn't converged since before PILC. I hope we can nail it down this time, at least better than we usually do.

Regards, Benoit

Spencer, as TSV AD

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 24 Sep 2015 12:10:38 +0000

》radio networks
I think the short answer is that there will be techniques/discussions that apply to any IP network. Radio resource control (including cell handover and UE movement) is possibly a unique scenario in mobile networks though - the Mobile Throughput Guidance I-D has a good explanation in the intro.

All best
Kevin

Salvatore Loreto <[email-masked]> wrote:

BR
Salvatore

Hi, Benoit,

Yes, exactly (IMO).

Regards, Benoit

Spencer, as TSV AD