Re: [Marnew] Marnew reflections

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Benoit,

On Wed, Sep 23, 2015 at 8:12 PM, Benoit Claise <[e-mail]> 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.

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?
>
> - 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
>

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

Spencer, as TSV AD