Internet DRAFT - draft-choi-httpbis-multi-location-return
draft-choi-httpbis-multi-location-return
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]
