Re: [Marnew] Marnew reflections

[Salvatore Loreto <[e-mail]>]

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:[e-mail]] On Behalf Of Spencer Dawkins at IETF
Sent: den 24 september 2015 03:15
To: Benoit Claise
Cc: [e-mail]
Subject: Re: [Marnew] Marnew reflections

Hi, Benoit,

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