Internet Engineering Task Force Attila Mihaly
Internet Draft Szilveszter Nadas
Intended status: Informational Ericsson
Expires: January 2016 July 6, 2015
Middlebox Communication Enabling for Enhanced User Experience
draft-mihaly-spud-mb-communication-00.txt
Abstract
In this draft we address some of the key discussion points related
to the scope of Substrate Protocol for User Datagrams (SPUD).
Specifically, we show how we can define the middlebox communication
framework such that it allows uneven resource sharing on the path
among the endpoints enhancing in this way the user experience.
Issues related to trust and incentives as well as how to support
user decisions in this eco-system are clarified.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 6, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mihaly Expires January 6, 2016 [Page 1]
Internet-Draft MB communication for enhanced QoE July 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
1. Introduction...................................................2
2. Beyond the equal share.........................................3
3. Incentive frameworks...........................................4
3.1. Economic incentive based cooperation......................5
3.2. Non-economic incentive based cooperation..................6
4. Use cases.....................................................10
4.1. Web acceleration.........................................10
4.2. Video streaming..........................................10
5. Endpoint control..............................................12
6. Security Considerations.......................................16
7. IANA Considerations...........................................16
8. Conclusions...................................................16
9. References....................................................16
9.1. Normative References.....................................16
9.2. Informative References...................................16
10. Acknowledgments..............................................17
1. Introduction
This internet draft relates to the recent IETF discussion around a
new prototype protocol called Substrate Protocol for User Datagrams
(SPUD)[SPUD_ML]. There is a wide range of opinions for the role of
such a substrate protocol, in the scale for "indication of session
start and stop for NATS" to "possibility of authenticated in-band
signaling channels" with no clear consensus. [SPUD92] describes that
SPUD is an extensible in-band channel that allows endpoints to
signal traffic meta-data to the middleboxes on the path. It also
provides a mechanism for the middleboxes to signal back to the same
endpoint using the same in-band channel.
The discussion around SPUD has identified a number of constraints on
the information exposed
o It is based on declarations only, thus no negotiation is needed
between the parties which reduces the communication latency.
There is also no assumption on what action (if any) will follow a
given declaration.
Mihaly Expires January 6, 2016 [Page 2]
Internet-Draft MB communication for enhanced QoE July 2015
o Endpoints/middleboxes may trust, but can verify the information
received. The best way to prevent cheating is to remove
incentives to do so.
o Incremental usefulness, no mandatory minimum vocabulary needed,
i.e. SPUD need not be supported by all nodes on a path before a
benefit is seen. All parties must ignore (and not delete) what
they don't understand. The sender must also assume it may not be
understood. This facilitates incremental deployment
Another constraint related to these was mentioned several times: the
exposed information shall not change the total share of the user
(from a bottleneck resource). This constraint highly decreases any
incentive of the user to cheat, but it also makes QoS solutions much
less efficient, because the networks must meet the QoS demand of the
most resource demanding service for all users all the time. This
might be possible in some networks (e.g. fixed line), but this is
much more challenging for the costly resources of cellular networks.
QoS solutions are available in cellular networks [CQOS]. It is the
role of Traffic Detection Function (TDF) to map the existing flows
to the cellular QoS. This function is challenged by encryption and
the current scope of SPUD does not help solving this challenge much.
In this draft we intend to explore how to make accessible the
existing QoS framework for encrypted traffic. We introduce incentive
frameworks which allow to both increase and decrease the resource
share of the user and which also have consequences on future shares.
We also explain how the endpoints can control their share without
having too much bothersome user interactions.
2. Beyond the equal share
Declarative markings that middleboxes may trust but can easily
verify originally aimed "to treat all markings on packets and flows
as relative to other markings on packets and flows from the same
sender". The main reason for this limitation was avoiding some of
the trust issues. Indeed, as long as the communication cannot
influence the overall resource share that a given user gets, there
could be little incentive for the user to send false information to
the path as any improper treatment would likely affect the user
traffic in a negative way.
We believe that this constraint restricts the communication
vocabulary too much. There is a significant potential in optimizing
the overall utility for both the network and the subscribers by
allocating resources unevenly when there is a congestion event. For
Mihaly Expires January 6, 2016 [Page 3]
Internet-Draft MB communication for enhanced QoE July 2015
example, by giving more resources to a web download than to a
background file transfer, the overall user satisfaction increases,
because the impact on user experience improves for the former
without significantly affecting the experience of the latter. An
eco-system would therefore be needed that allows temporal deviations
from the equal share of the different users sharing the same
resource.
There are a few pre-requisites for such eco-system to happen. The
first challenge is providing the right incentives for both the
endpoints and the network to cooperate along this paradigm. To
achieve this, the endpoints shall be able to select between service
options and perceive the benefits of their selection. A further
challenge is avoiding mis-use of a high resource-share service by
endpoints: by default the endpoints' interest would be to select to
use that service in all cases, regardless whether they really need
it or not. It should be possible by the network to impose by some
means that the endpoints select the more favorable service only if
they really need the respective treatment for their traffic.
Examples on how these targets can be achieved are detailed in
sections 3.1. and 3.2. Example use cases showing the benefits of
using the incentive frameworks are given in section 4.
A further aspect of uneven resource share allocation is the endpoint
control of how its different flows should be treated. Details on
this are in section 5.
3. Incentive frameworks
There are different potential solutions for cooperation between
endpoints and middleboxes that enables unequal resource sharing and
avoids mis-use by the endpoints. The one we describe here is
designed with the following features in mind:
o It builds on existing QoS architectures, i.e., it does not
require building a new QoS architecture.
o It requires a minimal update of the existing subscription models
(e.g. bucket-based charging)
o It is based on the decision of the endpoints, i.e., the users may
control which applications and when to use a specific service
delivery option
o It may be based on a declarative communication.
Mihaly Expires January 6, 2016 [Page 4]
Internet-Draft MB communication for enhanced QoE July 2015
o It is fair to the users: all users may have access to the same
type of service delivery option. Moreover, there are no
negatively discriminated users, including users that are not
willing to participate (they will receive the default service
delivery option all the time).
3.1. Economic incentive based cooperation
One possibility to avoid mis-use is to apply some penalty for using
the more favorable service. Examples of such penalties are
o Applying higher price for the better service. For example, the
Internet Service Provider (ISP) could introduce new service
delivery options besides the existing Interactive (I) one, e.g.,
o A real-time (RT) class (with low delay and jitter guarantees
up to a certain throughput threshold) and a higher cost per
bit
o A Lower-than-best-effort (LBE) class with looser throughput
delay and loss guarantees but a low cost per bit
o Applying limited caps for the better service. E.g. the same
service delivery options I/RT/LBE as before but having different
monthly caps (in bytes) for the new classes.
o Another option is to keep the single bucket per user solution,
but apply different bit-multipliers depending on the requested
treatment, for example:
o Real-time class: 3-10x multiplier (i.e. a single RT octet
results in decreasing the user's bucket by 3-10 octets)
o Interactive class: 1x multiplier, similar to today's BE
handling. Note that the operator may incentivize sending flow
meta-data by applying a smaller, e.g., 0.9x multiplier when
flow metadata is provided
o LBE: 0-0.3x multiplier
The above service offerings provide endpoints the possibility to
access to new services (RT class), generate (near) toll-free data
(LBE), and get access to better/cheaper interactive/video service,
giving the users incentives to use, but not to mis-use a given
class, because of the penalty applied. We consider the above service
offerings fair to the user as long as everyone has access to the
Mihaly Expires January 6, 2016 [Page 5]
Internet-Draft MB communication for enhanced QoE July 2015
same service categories for a fair price, and a service class is
handled the same way for all endpoints.
3.2. Non-economic incentive based cooperation
The incentive framework presented in section 3.1. provides a light-
weight solution from the points of view of service description
(SLAs), policy control and charging. Still, it may have issues with
ensuring service guarantees especially in cellular network due to
the shared, limited and costly radio resources. In this proposal the
operator provides soft service guarantees which do not imply extra
'cost' for the subscriber and therefore no strict guarantees are
provided for the different service options. Thus it does not face
the difficulties of the SLA based service offerings.
The basic idea is that the ISP offers different options in "service
delivery", e.g., a "background" service delivery option when there
is a need for additional network resources for some other traffic.
The users of this service delivery option are given relatively lower
resource share than if they were using the generic "best-effort"
(BE) service - thus other users can benefit from the fact that the
users using the "background" service delivery option can be down-
prioritized when accessing shared resources, e.g. a radio cell. In
turn, the ISP offers tokens, which are objects that represent the
right to perform a certain action. In this context, the users can
request a so-called "priority" service delivery option given that
they have accumulated tokens by using the "background" service
delivery option. Users thus are motivated to request the
"background" service delivery option when their traffic copes with
more relaxed network QoS.
The main concept is depicted in the example figures Figure 1
(indication and usage of "background" service delivery option) and
Figure 2 (request, acceptance and usage of "prioritized" service
delivery option).
Mihaly Expires January 6, 2016 [Page 6]
Internet-Draft MB communication for enhanced QoE July 2015
+------+ +--------------+ +--------+
| User | | Network Node | | Server |
+---+--+ +--------------+ +--------+
| 1:Session establishment |
<------------------------+------------------>
| | |
| +-----------+---------------+ |
| |2:Trigger for "background"| |
| | service delivery option | |
| +---------------------------+ |
| 3:"Background" possible| |
<------------------------+ |
+-------------------+ | |
| 4:Policy decision | | |
+-------+-----------+ | |
| 5:Apply for "backgrnd" | |
+------------------------> |
| +-----------+------------+ |
| | 6:Change flow handling | |
| +-----------+------------+ |
| +---------+----------+ |
| | 7:Accumulate token | |
| +---------+----------+ |
| 8:Session ended |
<------------------------+------------------>
| 9: Service report | |
<------------------------+ |
+ + +
Figure 1 Example sequence diagram illustrating the background
service delivery option offering and accumulation of the tokens by
user by using the background service delivery option
Description of Figure 1 for the indication and usage of "background"
service delivery option:
1. There is a session established between the User and Server that
is susceptible for "background" service delivery option, but
currently using the normal service
2. At a given time, the network experiences congestion in the
region that involves also the session previously mentioned.
Based on this, a trigger is generated for the possibility of
using "background" service delivery option
Mihaly Expires January 6, 2016 [Page 7]
Internet-Draft MB communication for enhanced QoE July 2015
3. A notification that the "background" service delivery option is
possible is sent to impacted users, thus also to the user in
this sequence chart.
4. There is a policy decision by the user whether the conditions
are such that the given session may use the "background"
service delivery option
5. If the decision is "yes", then the user applies for the
"background" service delivery option for this session
6. The network changes the flow handling of the given session
according to the "background" policy
7. At this point the network also starts to accumulate tokens for
the given user
8. When the session ends,
9. The network may send a service report to the user including
e.g., the session identification that used the background
service delivery option, the time elapsed, traffic volume sent,
tokens accumulated etc.)
Mihaly Expires January 6, 2016 [Page 8]
Internet-Draft MB communication for enhanced QoE July 2015
+------+ +--------------+ +--------+
| User | | Network Node | | Server |
+---+--+ +--------------+ +--------+
| 1:Session establishm|ent |
<------------------------------------------->
+-------------------+ | |
| 2:Policy decision | | |
+--------+----------+ | |
| 3:Apply for "prio" | |
+------------------------> |
| +-------------------+ |
| | 4:Policy decision | |
| +-------------------+ |
| 5:"Prioritize" possible| |
<------------------------| |
| +------------------------+ |
| | 6:Change flow handling | |
| | Consume tokens | |
| +------------------------+ |
| 7:Session ended |
+------------------------+------------------>
| 8:Service report | |
<------------------------| |
Figure 2 Example sequence diagram illustrating the request and
utilization of prioritized service delivery option by the user based
on accumulated tokens
Figure 2 depicts an example of requesting, acceptance and usage of
'prioritized' service delivery option:
1. There is a session established between the User and
2. At a given time the policy decision in the client triggers that
the given session may benefit from "prioritized" service
delivery option for improved QoE
3. A request for "prioritized" service delivery option is sent to
the network
4. The network takes a policy decision on applying the
"prioritized" service delivery option for user
Mihaly Expires January 6, 2016 [Page 9]
Internet-Draft MB communication for enhanced QoE July 2015
5. If the decision is "yes", then the network send a "Prioritized
service delivery option acknowledged" notification to the user
6. At the same time, the network changes the flow handling of the
given session according to the "prioritized" policy and it also
starts to consume tokens for the given user
7. When the session ends
8. The network may send a service report to the user including
e.g., the session identification that used the "prioritized"
service, the time elapsed, traffic volume sent, tokens spent
etc.)
4. Use cases
The purpose of this section is to show that there are common use
cases where the incentive frameworks previously defined give
benefits for the endpoints.
4.1. Web acceleration
A simple example using the non-economic incentive framework in 3.2.
is when a user downloading software updates starts gathering tokens
(given that is notified that due to high cell load he is eligible
for "background" service delivery option). Afterwards it uses the
accumulated tokens for his critical traffic, e.g. for the
prioritized download of the critical content of a web page to
shorten the time until rendering starts.
4.2. Video streaming
Below we give another example related to streaming video, also using
the incentive framework in 4.2. The idea is that the user asks for
"background" or "prioritized" service delivery option depending on
the current play-out buffer level. An example selection algorithm is
described in Figure 3, where the service delivery option decisions
in the client are taken based on the threshold levels in Figure 4
(here we made it apparent that the concept may be applied also for
adaptive i.e., DASH videos; the client has a buffer-based algorithm
for choosing a specific quality representation in this example). The
"prioritized" service delivery option provides relative
prioritization for low buffer levels. In this way video freeze
events due to buffer underrun may be avoided or at least reduced and
pre-buffering times also reduced, improving the QoE of the users.
Once the buffer occupancy reaches a level that is considered safe
for avoiding the video freeze the client may switch back to the
normal service. If the buffer occupancy further increases reaching
comfortable values then the user/application may apply for
Mihaly Expires January 6, 2016 [Page 10]
Internet-Draft MB communication for enhanced QoE July 2015
"background" service delivery option in order to accumulate tokens
for further potential low-buffer events.
normalService:
if (buffer > Max1Threshold and networkOfferAvailable) {
askForService("background");
goto backgroundService;
}
if (buffer < Min1Threshold and isTokenAvailable()) {
askForService("priority");
goto priorityService;
}
wait();
goto normalService;
backgroundService:
if (buffer < Max2Threshold) {
askForService("normal");
goto normalService;
}
wait();
goto backgroundService;
priorityService:
if (buffer > Min2Threshold) {
askForService("normal");
goto normalService;
}
wait();
goto priorityService;
Figure 3 Example pseudocode for different service delivery options
for the streaming video case
Mihaly Expires January 6, 2016 [Page 11]
Internet-Draft MB communication for enhanced QoE July 2015
| LQ | MQ | HQ
<---------------->|<------>|<-----------------
| | |
+------+-----+----+--------+--+------+-----...
| | | | | | |
| | | | | | |
+------+-----+----+--------+--+------+-----...
^ ^ ^ ^
| | | |
| | | |
Min1Th Min2Th Max2Th Max1Th
Figure 4 Example streaming video buffer thresholds for service
delivery option and representation switches (LQ/MQ/HQ= buffer size
ranges where the media client requests Low/Medium/High Quality
representation chunks, respectively)
5. Endpoint control
The use cases for non-equal share treatment illustrated that the
treatment to be selected for different applications may vary from
application to application and may also vary during a session using
a certain application.
In order to be fair to users and applications the users should have
the control on which applications and when to use a specific service
option. Indeed, having a stipulated treatment of certain application
may result in positive or negative discrimination of the
corresponding service provider. The endpoints should be provided the
opportunity to opt in for certain treatment for different
applications, or ultimately to not require any of the different
service options. For example, any of the following user types should
be possible in the eco-system:
o Bit-pipe enthusiast: wanting to get the same equal-share bit-pipe
service as today for all his applications at all times
o Default user: being aware of the mutual advantage of using
unequal share and wanting to cooperate, but not bothering about
or not having the necessary technical knowledge to control its
different applications. There should be some default operator or
community settings that such types of users may rely on
Mihaly Expires January 6, 2016 [Page 12]
Internet-Draft MB communication for enhanced QoE July 2015
o Biased user: considers only one type of service as important and
wants to enjoy it with highest possible QoE. For example, a video
fan being offered the service options presented in 3.2. would
accept all offers for "background" service delivery option for
all its applications except video, and would spend all its
accumulated tokens on enhancing its preferred video application.
o Premium user: wanting to get as much quality out of the network
service as possible and wanting to pay extra for it.
A common need for all these different user types is the ability of
monitoring of the KPIs of the service delivery and possibility for
understanding and verification of the advantages received by
choosing a certain service delivery option.
Both service control and service monitoring would be quite
cumbersome for the users so it requires some support, i.e., means to
delegate the user choices either to user operating system (OS) or a
separate application. Let us call this application the Quality of
Experience Controlling Application (QCA). An example on QCA
functionality is shown in Figure 5: QCA takes the role of
communication with the network, i.e., it receives network
notifications and sends service delivery option requests. In order
to be able to send meaningful service delivery option requests, QCA
should have access to the information about the applications that
may use different service options, e.g., when they use the network
resources, their identification (e.g., five-tuple) and potentially
about the experienced QoE for these applications. This is shown by
steps 4 (identification of APPs with on-going flows that are
potential candidates for the background service delivery option) and
5 (inquiring their state) in Figure 5.
The QoE Controlling Application (QCA) makes the policy decision as
in step 6 in Figure 5 and may also keep a statistics about different
service options usage based on the service reports received in step
11. QCA should have a user front-end, where the user may configure
its desired policy settings, i.e. which applications and in which
conditions may be downgraded to the "background" service delivery
option and which are those and in which conditions that could
benefit from the "prioritized" service delivery option. The
complexity of this user interface should be reduced such that QCA
should be able to run in the background, i.e., the user should not
be forced to acknowledge a certain policy behavior during its
session. There may be different options to achieve this, for
example, the user could be offered a number of default settings
provided e.g., by the operating system vendor, or the ISP when
installing the QCA to the user device so that the user is only
Mihaly Expires January 6, 2016 [Page 13]
Internet-Draft MB communication for enhanced QoE July 2015
required to configure these settings if he wants to have some
particular changes. Community databases for default user settings
similar to AdBlockPlus plugins [ABPF] could also be quite useful
options to select from.
Mihaly Expires January 6, 2016 [Page 14]
Internet-Draft MB communication for enhanced QoE July 2015
+----------------+
|User |
+------+ +------+ +--------------+ +--------+
|| APP | | QCA || | Network Node | | SerVer |
|------+ +------| +--------------+ +--------+
+-+----------+---+ 1:Session estab|lishment |
<----------+------------------------------------------->
| | | |
| | +-----------+---------------+ |
| | |2:Trigger for "background"| |
| | | service delivery option | |
| | +---------------------------+ |
| | 3:"Background" possible| |
| <------------------------+ |
| +----------------+ | |
| | 4:Identify APP | | |
| +----------------+ | |
| 5:Inquire| | |
<----------> | |
| state | | |
| | | |
| +-------+-----------+ | |
| | 6:Policy decision | | |
| +-------+-----------+ | |
| | 7:Apply for "backgrnd" | |
| +------------------------> |
| | +------------------------+ |
| | | 8:Change flow handling | |
| | +------------------------+ |
| | +--------------------+ |
| | | 9:Accumulate token | |
| | +--------------------+ |
| | 10:Session ended |
| <------------------------+------------------>
| | 11: Service report | |
| <------------------------+ |
+ + + +
Figure 5 Example sequence chart showing the role of QCA in the
example background service delivery option offering and usage by an
application APP in Figure 1
Mihaly Expires January 6, 2016 [Page 15]
Internet-Draft MB communication for enhanced QoE July 2015
6. Security Considerations
There are a number of security considerations, which is TBD to
clarify and write down. The general consensus within SPUD discussion
is to experiment first and then deal with security considerations.
This draft has been written in this spirit.
7. IANA Considerations
The current draft does not pose any IANA considerations
8. Conclusions
In this draft we explore how to make the existing QoS framework
accessible for encrypted traffic, based on authenticated declarative
communication that may be carried over SPUD. We defined an incentive
framework that allows the usage of different service options and
discourages the mis-use of them. We also showed how the users can
control access to the different service options without having too
much bothersome user interactions.
This work is not complete, future work is needed in the following
areas:
o How could the framework be extended to service providers to
declare their intent and receive different service options
o What are the required changes to endpoint architectures for a
simplified endpoint control
o Community discussion on how the proposed framework relates to the
net neutrality principle, and what measures are needed to ensure
that
o How to provide security for the communication
o Identification of the right forum for this discussion, if not
SPUD.
9. References
9.1. Normative References
9.2. Informative References
[SPUD_ML] SPUD mailing list, see http://www.ietf.org/mail-
archive/web/spud/current/maillist.html
Mihaly Expires January 6, 2016 [Page 16]
Internet-Draft MB communication for enhanced QoE July 2015
[SPUD92] Brian Trammel, Substrate Protocol for User Datagrams
https://www.ietf.org/proceedings/92/slides/slides-92-spud-
1.pdf
[CQOS] Reiner Ludwig et all, "An Evolved 3GPP QoS Concept", VTC
2006 Spring
[ABPF] https://adblockplus.org/subscriptions, checked 2015-07-06
10. Acknowledgments
This document is the result of discussion in the SPUD mailing list
and internally within Ericsson. We thank all who participated.
This document was prepared using 2-Word-v2.0.template.dot.
Mihaly Expires January 6, 2016 [Page 17]
Internet-Draft MB communication for enhanced QoE July 2015
Authors' Addresses
Attila Mihaly
Ericsson
Budapest
Hungary
Email: attila.mihaly@ericsson.com
Szilveszter Nadas
Ericsson
Budapest
Hungary
Email: szilveszter.nadas@ericsson.com
Mihaly Expires January 6, 2016 [Page 18]