Internet DRAFT - draft-loreto-wpd-usage
draft-loreto-wpd-usage
Network Working Group D. Druta
Internet-Draft G. Bourg
Intended status: Informational AT&T
Expires: April 30, 2015 S. Loreto
Ericsson
October 27, 2014
Using WPD to configure network proxies
draft-loreto-wpd-usage-00
Abstract
This specification provides feedbacks and improvements suggestions to
"The Web Proxy Description Format" draft. It is an initial set of
considerations collected while reviewing the WPD draft to understand
how it could be used in a Telecom Operator network; specifically
Cellular and Operated WiFi Networks.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Druta, et al. Expires April 30, 2015 [Page 1]
Internet-Draft WPD Usage October 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. WPD Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Traffic Flow label . . . . . . . . . . . . . . . . . . . 2
2.2. Web Protocol . . . . . . . . . . . . . . . . . . . . . . 4
3. The Web Proxy Description (WPD) Format . . . . . . . . . . . 4
3.1. proxy objects members . . . . . . . . . . . . . . . . . . 5
3.1.1. Label . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. WebProtocol . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Draft [I-D.nottingham-web-proxy-desc] presents a simple and reliable
way to describe a Web Proxy Configuration (WPD), and proposes the
usage of a well-known URI [RFC5785] to designate a well-know location
where the WPD can be found.
The WPD allows the description of multiple proxies in one WPD file as
long as they are under the same authority; clients may choose any
proxy they wish, and may use more than one proxy at a time. However
the proxy description should be extended to provide better user
experience and smoother interaction with the network.
2. WPD Proxies
[I-D.nottingham-web-proxy-desc] defines the "WPD Proxy" concept and
place additional requirements upon this proxy, as well as upon
clients using it. The following sections proposes improvements and
changes to those requirements.
2.1. Traffic Flow label
3GPP Mobile Networks support Traffic Flow Templates that allow
specific flows to traverse different data bearers; a flow is
identified by the 5-tuple {dest addr, source addr, protocol, dest
port, source port}. These data bearers can have different
characteristics based on how they are configured. Specifically, in
scheduled networks there is an inherent balancing act between
absolute data rate, latency, and jitter. Today 3GPP mobile networks
Druta, et al. Expires April 30, 2015 [Page 2]
Internet-Draft WPD Usage October 2014
balance the needs of different types of traffic (e.g. the high bit
rate download that is unaffected by jitter vs real time
communications that are lower bit rate but require minimal jitter or
latency impact) by detecting traffic and assigning flows to bearers
that are best configured for the type of traffic. Traffic
classification is not used to discriminate between clients or between
servers. Instead, it is necessary to optimally utilize the radio
resources resulting in improved user experience.
WPD proxy mandates the usage of HTTP2 [I-D.ietf-httpbis-http2] over
TLS for connections from clients.
The usage of a single TCP connection to an addressable and explicit
proxy provides several benefits, however at same time it prevents a
3GPP mobile network from working as previously described, because it
is not possible to de-multiplex the traffic within the single TCP
socket into multiple data bearers. For a 3GPP mobile network, this
limits the ability to tune the network efficiently based on traffic
classification.
As draft [I-D.nottingham-web-proxy-desc] already allows a client to
choose multiple proxies to be used at a time, it should be possible
for a client to use multiple proxies for different purposes as long
as it is clear to the client the different type of advantages offered
by each proxy listed in the retrieved WPD file. In this way a
different proxy instance could be used for flows of each traffic
type.
This document defines a new WPD's "proxy object" member ("label"),
describing the purpose and the specific services offered by a proxy.
Labels can be used by the client to identify the right proxy that
should be used for a specific traffic type or them can be used to
identify proxies offering specific optimisation functions.
A client can use the "label" member to identify the right proxy to be
used for a specific class of traffic (e.g. "dft" for a traffic
balance between latency and jitter, "rtc" for low bandwidth but
jitter sensitive real time communications, or "hdr" for High Data
Rate traffic that is unaffected by jitter). The client is, in many
situations, able to determine from the context of an HTTP transaction
what type of "label" to apply to an http resource. The client may
then decide to map the label's resource with the proxy with the same
label listed in the retrieved WPD or to use the default proxy.
Additionally, it should be possible for the content provider to
explicitly label resources to suggest they traverse a specific proxy
path.
Druta, et al. Expires April 30, 2015 [Page 3]
Internet-Draft WPD Usage October 2014
2.2. Web Protocol
"Clients MUST use HTTP/2 over TLS to connect to a WPD proxy; if
one cannot be established, the client MUST consider that proxy
"failed"."
Using TLS to provide security, confidentiality and integrity is an
important requirement to have. However restricting the possibility
to establishing connection from client only to "HTTP/2 over TLS"
closes the door to innovation. It would much better to define a list
of criteria that protocol has to fulfil in order to be used between a
Client and a WPD Proxy. In order to maximize interoperability,
HTTP/2 MUST be mandatory to implement, however other protocols that
meet the minimum requirements may also be used.
A possible but not complete list of requirements can be: "The
protocol session between the client and server must use a multiplexed
and flow controlled protocol. This is necessary to effectively scale
the proxy server and provide differentiated service priority between
requests while protecting resource constraints on both ends. The
reduction in connection count is particularly meaningful to an
intermediary, and the protocol support for prioritization is needed
to mitigate the change in connection granularity."
3. The Web Proxy Description (WPD) Format
The proxy information currently defined in the WPD proposal should be
extended in order to both provide a better user experience and a
smoother interaction with the network. For example:
Druta, et al. Expires April 30, 2015 [Page 4]
Internet-Draft WPD Usage October 2014
{
"name": "ExampleCorp Web Proxy",
"desc": "ExampleCorp's Proxy Gateway for Web access. Note that
all traffic through this proxy is logged, and may be
filtered for content.",
"moreInfo": "https://inside.example.com/proxy/",
"proxies": [
{
"host": "proxy.example.com",
"port": 8080,
"clientNetworks": ["192.0.2.0/24"]
"label": "dft"
"WebProtocol": "h2"
},
{
"host": "proxy1.example.com",
"port": 8080,
"clientNetworks": ["192.0.2.0/24"]
"label": "rtc"
"WebProtocol": "h2"
}
],
"alwaysDirect": ["example.com", "192.0.2.0/24"],
"failDirect": False
}
The reminder of this section defines the proposed extensions of the
WPD object members.
3.1. proxy objects members
A proxy object as defined in [I-D.nottingham-web-proxy-desc]
represents a HTTP proxy endpoint within the WPD JSON representation.
At moment the only Proxy objects' "label" value defined are the
following "host", "port", "clientNetworks".
The following sections define new members necessary to completely
describe a WPD Proxy.
3.1.1. Label
A string containing the tag specifying the class of traffic. This
specification defines the following three three labels:
dft: a traffic class with balance between latency and jitter;
Druta, et al. Expires April 30, 2015 [Page 5]
Internet-Draft WPD Usage October 2014
rtc: a traffic class for low bandwidth but jitter sensitive real
time communications;
hdr: a traffic class for High Data Rate traffic that is unaffected
by jitter.
It should be possible to use implementation defined labels for which
the Client MUST use the label on the http resource URL to send the
request to the corresponding proxy entry in the WPD. If the label
does not have a matching entry, the Client MUST use the default proxy
(dft).
[TBD] create a new IANA register for the label.
3.1.2. WebProtocol
A string containing the ALPN tag [RFC7301] describing the protocol
supported by the proxy to establish a session between the client and
proxy itself. This member MUST be present.
4. IANA Considerations
This specification creates a new IANA registry, in accordance with
the principles set out in [RFC5226], for the "label" Proxy objects'
parameter namespace describing the specific class of traffic or
optimisation feature provided by a proxy.
5. Security Considerations
See [I-D.nottingham-web-proxy-desc] for general security
considerations on the WPD usage.
It should be noted that the usage of multiple proxies, proposed in
this document, discloses the type of traffic requested and used by
the client (i.e. the end user).
6. Acknowledgments
The authors wish to thank Diego Lopez, Kevin Smith, Martin Nilsson,
Sanjay Mishra and Mathilde Cayla for their comments and useful
feedback.
7. Normative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-14 (work in
progress), July 2014.
Druta, et al. Expires April 30, 2015 [Page 6]
Internet-Draft WPD Usage October 2014
[I-D.nottingham-web-proxy-desc]
Nottingham, M., "The Web Proxy Description Format", draft-
nottingham-web-proxy-desc-01 (work in progress), October
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, April
2010.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014.
Authors' Addresses
Dan Druta
AT&T
Email: dd5826@att.com
Gus Bourg
AT&T
Email: gb3635@att.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Druta, et al. Expires April 30, 2015 [Page 7]
