Network Working Group T. Choi Internet-Draft ETRI Intended Status: Standard Track J. Shinn Expires: January 16, 2014 Solbox Inc. J. Lee SKT J. Koo LGU+ Y. Seo KT July 15, 2013 HTTP 2.0 Extension for Multi-location Return for Redirection draft-choi-httpbis-multi-location-return-00 Abstract This document proposes a mechanism to enhance redirection mechanism of the HTTP1.1 so that it can improve the web service availability. 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 TS. Choi Expires January 16, 2014 [Page 1] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current HTTP Redirection Procedure and Issues . . . . . . . . 3 3. HTTP Redirection with Multi-locations Return . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 5. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. CDNi HTTP-based Redirection with Multi-location Return . . 6 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 TS. Choi Expires January 16, 2014 [Page 2] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 1 Introduction For generic content delivery services, the high availability is a major issue as most contents provider wants more than 99% availability for their services. Response time is also a major issue as it might be the main reason why contents providers use CDN services. However, due to limitation of redirection feature of HTTP/1.1, unnecessary connection cost and point of failures are expected on certain situation. This document describes such situation and a suggestion for enhanced way to avoid those situation. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Current HTTP Redirection Procedure and Issues In this section, we describe an example of legacy HTTP-based redirection and problems it may have. User agent Svr-www Svr-www2 Svr-www3 | | | | |GET www.example.com/sample.zip HTTP/1.1 | |(1) |--------------------------------->| | | | | | | |302 www2.example.com/sample.zip HTTP/1.1 | |(2) |<---------------------------------| | | | | | | |GET www2.example.com/sample.zip HTTP/1.1 | |(3) |-------------------------------------------->| | | | | | |200 OK HTTP/1.1 | | |(4) |<--------------------------------------------| | | DATA | | | Figure 1: HTTP/1.1 based redirection example The above figure is an example of HTTP/1.1 based redirection with following steps: (1) Request sample.zip to www.example.com (2) Redirection to www2.example.com (3) Request sample.zip to www2.example.com TS. Choi Expires January 16, 2014 [Page 3] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 (4) Receive sample.zip from www2.example.com However, if www2 server went down or become unreachable during step (3), the user agent has nowhere else to request anything but just printing out error message to the end-user. Even though svr-www3 is ready to serve, there is no way to redirect the request of the user agent with legacy HTTP/1.1. Just after svr-www sends 302 message to the user agent, svr-www completely lose the control of this transaction. One of legacy solution for this problem is using L4 switch capability. However, when using L4 switch to avoid this problem, all of the servers needed to be in same network area, not to mention high price of L4 switches. Another legacy solution is DNS based GSLB(Global Server Load Balance). DNS based GSLB can easily be deploied for the servers in different networks. They are also less expensive than L4 switch solution (usually). Nevertheless, there are still problems. As it is based on DNS protocol, it cannot change the path of URL. Furthermore, even if GSLB monitors the status of servers, the problem still remain if a server goes down just right after the redirection. 3. HTTP Redirection with Multi-locations Return The following figure describes the situation that if HTTP supports multi-location return. User agent Svr-www Svr-www2 Svr-www3 | | | | |GET www.example.com/sample.zip HTTP/2.0 | |(1) |--------------------------------->| | | | | | | |302 www2.example.com/sample.zip HTTP/2.0 | |(2) | www3.example.com/sample.zip HTTP/2.0 | | | www.example.com/sorry.html HTTP/2.0 | | |<---------------------------------| | | | | | | |GET www2.example.com/sample.zip HTTP/1.1 | |(3) |-------------------------------------------->| | | | | | |connection fail | | |(4) |<--------------------------------------------| | | | | | |GET www2.example.com/sample.zip HTTP/1.1 | |(5) |------------------------------------------------------->| | | | | |200 OK HTTP/1.1 | | |(6) TS. Choi Expires January 16, 2014 [Page 4] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 |<-------------------------------------------------------| | DATA | | | Figure 2: Example of HTTP-based Redirection with multi location return The above figure is an example of HTTP/1.1 based redirection with following steps: (1) Request sample.zip to www.example.com (2) Provide redirection-url-list to user agent (3) Request sample.zip to www2.example.com (4) Connection to www2 failed (5) Retry to receive sample.zip from www3.example.com (6) Receive sample.zip from www3.example.com With this procedure, the user agent can try other URLs from the location list. The above step is just an example, and it can be expanded or developed with other ideas. Such as, like step (2) of figure 2, placing www server itself at the list, the user agent can come back to www server even if it fails to connect to every other servers. 4. Backward Compatibility As there are so many clients that support HTTP/1.1 with single location return, it will take some time for them to upgrade with multi locations return capability. Thus we need to consider backward compatibility of this feature. The following is an example of using location tag with HTTP/1.1 or older versions. HTTP/1.1 302 Location: http://www.example.com/sample.zip Regarding the above example, rather than replacing a legacy location tag, just keeping the original location tag and adding an extension tag shall give backward compatibility to all types of clients. The example is as following: HTTP/2.0 302 Location: http://www.example.com/sample.zip M-Location: http://www.example.com/sample.zip http://www2.example.com/sample.zip http://www3.example.com/sample.zip M-Redirection-Count: 0 In this way, legacy clients can parse the location tag as usual, and TS. Choi Expires January 16, 2014 [Page 5] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 new client which supports the multiple location tag can utilize additional M-Location tag. Note that M-Redirection-Count specifies the maximum number of allowed redirections. It can be used to limit the number of redirection for protecting a redirection loop. 5. Use Case 5.1. CDNi HTTP-based Redirection with Multi-location Return The following figure describes the situation that if HTTP supports the return of multiple locations in CDN interconnection environment[draft-choi-cdni-req-intf]. The details of CDN interconnection architecture and mechanisms are defined in the [draft-ietf-cdni-framework]. In this use case, we assume that the readers understand CDN interconnection mechanism. The relevant steps are step 2 and 12. In step 2, multiple request routing redirection CDN locations are returned upon the request routing redirection request by the end-user. In step 12, it is applied in the case of content acquisition between CDN providers. End-User dCDNn dCDNn-1 dCDN1 uCDN |DNS cdn.csp.com | | | | |------------------------------------------------------->| | | | | |(1) |IPaddr of uCDN's Request Router | | | |<-------------------------------------------------------| |HTTP cdn.csp.com | | | | |------------------------------------------------------->| | | | | |(2) |302 peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID, | | peer-uCDN.dCDN2.net/cdn.csp.com?uCDN-Provider-ID, | | peer-uCDN.dCDNN.net/cdn.csp.com?uCDN-Provider-ID, | | peer-uCDN.uCDN.net/cdn.csp.com?uCDN-Provider-ID | |<-------------------------------------------------------| |DNS peer-uCDN.dCDN1.net | | | |-------------------------------------------->| | | | | |(3) | |IPaddr of dCDN1's Request Router| | | |<--------------------------------------------| | | | | | | |HTTP peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID | |-------------------------------------------->| | | Connection fail | | |(4) | |<--------------------------------------------| | |DNS peer-uCDN.dCDN2.net | | | TS. Choi Expires January 16, 2014 [Page 6] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 |------------------------------->| | | | | | |(3) | |IPaddr of dCDN1's Request Router| | | |<--------------------------------------------| | | | | | | |HTTP peer-uCDN.dCDN2.net/cdn.csp.com?uCDN-Provider-ID | |-------------------------------------------->| | | Connection fail | | |(4) | |<--------------------------------------------| | | | | | | | | ....... |(5) | |<-------------------------------| | | | | | | | |DNS peer-dCDNn-1.dCDNn.net | | | |------------------------------->| | | | | |(6) | | |IPaddr of dCDNn's Request Router| | | |<-------------------------------| | | | | | | | |HTTP peer-dCDNn-1.dCDNn.net/cdn.csp.com | | |------------------------------->| | | | | |(7) | | |302 node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com | | |<-------------------------------| | | | | | | | |DNS node1.peer-dCDNn-1.dCDNn.net| | | |------------------>| | | | | | |(8) | | |IPaddr of dCDNn's Delivery Node } | | |<------------------| | | | | | | | | |HTTP node1.peer-dCDNn-1.dCDNn.net/cdn.csp.com| | |------------------>| | | | | |(9) | | | | |DNS dCDNn-acq.dCDNn-1.net| | | |----------->| | | | | |(10) | | | |IPaddr of dCDNn-1's Request Router | | |<-----------| | | | |HTTP dCDNn-acq.dCDNn-1.net?dCDNn-Provider-ID | |----------->| | | | | |(11) | | | | | ....... | | | | | | | | |HTTP dCDN1-acq.uCDN.net?dCDN1-Provider-ID | | | |--------->| | | | | |(12) | | |302 node2.dCDN1.acq.uCDN.net, TS. Choi Expires January 16, 2014 [Page 7] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 | | | node3.dCDN1.acq.uCDN.net, | | | origin.csp.com | | | | |<---------| | | |DNS node2.dCDN1-acq.uCDN.net | | | |--------->| | | | | |(13) | | |IPaddr of uCDN's Delivery Node2 | | | |<---------| | | | | |(14) | | | | Connection fail | | | |<---------| | | |DNS node3.dCDN1-acq.uCDN.net | | | |--------->| | | | | |(13) | | |IPaddr of uCDN's Delivery Node3 | | | |<---------| | | | | |(14) | | | | Connection fail | | | |<---------| | | |DNS origin.csp.com | | | |--------->| | | | | |(13) | | |IPaddr of csp's origin server | | | |<---------| | | | | |(14) | | | | Data | | | |<---------| | | | ....... | | |Data | | | | |<------------------| | | | Figure 1: HTTP-based request routing redirection iterative procedure with return of multiple locations TS. Choi Expires January 16, 2014 [Page 8] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 6 Security Considerations TBD. 7 IANA Considerations TBD. 8 References 8.1 Normative References [I-D.choi-cdni-req-intf] Choi, T., Shinn, J., Lee, J., Koo, J., Seo, Y., "Request Interface for CDN Interconnection", draft-choi-cdni-req-intf-00 (work in progress), July 2013. [I-D.ietf-cdni-framework] Peterson, L. and B. Davie, "Framework for CDN Interconnection", February 2013. 8.2 Informative References TBD. Authors' Addresses Taesang Choi ETRI 161 Gajong-Dong Yusong-Gu, Daejeon Republic of Korea Phone: +82-42-860-5628 Email: choits@etri.re.kr John Dongho Shinn Solbox Inc. 7F, Haesung Bldg. 747-2 Yeoksam-Dong Kangnam-Gu, Seoul Republic of Korea Phone: +82-10-3005-4785 Email: eastsky@solbox.com Jongmin Lee SK Telecom TS. Choi Expires January 16, 2014 [Page 9] INTERNET DRAFT Extension for Multi-location Return July 15, 2013 11, Euljiro-2ga Jung-gu, Seoul Republic of Korea Phone: 82-10-9429-6260 Email: jminlee@sk.com Ja-Ryeong Koo LG U plus Corporation Namdaemunro 5-ga Jung-gu, Seoul Republic of Korea Phone: 82-10-8080-6115 Email: wjbkoo@lguplus.co.kr Young-IL Seo KT Network R&D Laboratory 463-1, Jeonmoin-dong, Yuseong-gu, Daejeon Republic of Korea Phone: 82-10-3235-0135 Email: yohan.seo@kt.com TS. Choi Expires January 16, 2014 [Page 10]