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]