Skip to main content

Use-cases for Flow Tagging
draft-deng-httpbis-urlid-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Deng Lingli , Yong Xia , Shihui Duan
Last updated 2015-10-19
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-deng-httpbis-urlid-00
HTTPBIS Working Group                                            L. Deng
INTERNET-DRAFT                                              China Mobile
Intended Status: Informational                                    Y. Xia
Expires: April 20, 2016                                      China SARFT
                                                                 S. Duan
                                                                    CATR
                                                        October 19, 2015

                       Use-cases for Flow Tagging
                      draft-deng-httpbis-urlid-00

Abstract

   This document discusses the motivation and use-cases for coding flow
   tags into resource identification, e.g. URL.

Status of this Memo

   This Internet-Draft is submitted to IETF 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2013 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
 

<Deng, et al.>           Expires April 20, 2016                 [Page 1]
INTERNET DRAFT        <Use-cases for Flow Tagging>          Oct 19, 2015

   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Problem Statement . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  4
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  4
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  5
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6

 

<Deng, et al.>           Expires April 20, 2016                 [Page 2]
INTERNET DRAFT        <Use-cases for Flow Tagging>          Oct 19, 2015

1  Introduction

   The interconnect settlement between the network operators is based on
   traffic settlement. Because of lack of Internet content resources,
   the service requests from the small operators usually are redirected
   to the large operators, which leads to the imbalanced traffic
   patterns between the small operators and the large operators and
   force the small operators to pay high cost of traffic settlement to
   the large operators.

   To cut short the expense of traffic settlement, deploying a local
   cache system on the point of interconnection and interworking between
   two operators is the most direct method taken by the small operators
   to localize the traffic by caching hot content and avoid cross-
   boundary expenses for subsequent requests for cached content
   retrievals.

2  Problem Statement 

   As stated earlier, cache systems are considered to be an effective
   way to reduce the prohibitive expense for cross-boundary traffic from
   large ISP with most ICPs to small ISPs providing local services to a
   specific group of subscribers. The cache system automatically buffers
   the hotspot resources locally and reduces the traffic from the large
   operators by feeding the requested content locally.

   However, observed from the reality of operating, the local cache
   system can't fully implement traffic localization, as there are vast
   user requests redirected to other operators by DNS, even when the
   requested content is actually cached locally. 

   The main reason is that the work pattern of cache system is fully
   passive and the cache system uses the DPI technology to acquire the
   URL to identify for buffered content and match them with subsequent
   content requests, which causes undesirable cache misses in the
   following two cases:

   On the one hand, for video websites using the anti-stealing-link
   mechanism, which updates the URL for the same content periodically
   with new ones, subsequent requests are therefore subject to change
   even from the same website. 

   On the other hand, for the requests from the local subscribers to
   different websites, the cache system cannot recognize a content hit
   even if the content they are requesting are identical, as their URLs
   are likely to be different.

 

<Deng, et al.>           Expires April 20, 2016                 [Page 3]
INTERNET DRAFT        <Use-cases for Flow Tagging>          Oct 19, 2015

3  Requirements

   In order to improve the hit ratio and actively push the hot resources
   to the local subscribers, the cache system need a succinct way to
   learn the buffered contents and can judge the hot content according
   to the actual content information. It is preferable that no influence
   to the current application and its protocols.

4  Discussion

   Content tagging is expected to be helpful to address these
   requirements. E.g. to mark the content information and encode this
   flag/tag into the content's URL, which identifies its binary content
   and other application metadata. The cache system can know the exact
   content by analyze the content flag in the URL link and need no
   changes to any protocol.

5  Security Considerations

   TBA.

6  IANA Considerations

   There is no IANA action in this document.

7  Acknowledgements

   TBA.

 

<Deng, et al.>           Expires April 20, 2016                 [Page 4]
INTERNET DRAFT        <Use-cases for Flow Tagging>          Oct 19, 2015

8  References

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

 

<Deng, et al.>           Expires April 20, 2016                 [Page 5]
INTERNET DRAFT        <Use-cases for Flow Tagging>          Oct 19, 2015

Authors' Addresses

   Lingli Deng
   China Mobile

   Email: denglingli@chinamobile.com

   Yong Xia
   China SARFT

   Email: xiayong@abs.ac.cn

   Shihui Duan
   China Academy of Telecommunication Research of MIIT

   Email: duanshihui@catr.cn

<Deng, et al.>           Expires April 20, 2016                 [Page 6]