Subject: [alto] ALTO and Content Delivery Networks

From: Reinaldo Penno <[email-masked]>
Date: Fri, 4 Jun 2010 12:09:15 -0400

We posted a new Internet Draft on ALTO and CDNs

http://www.ietf.org/id/draft-penno-alto-cdn-00.txt

Regards,

Reinaldo

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 4 Jun 2010 09:44:46 -0700

Unforutately on the use-case, 302 redirections are often regarded as significantly inferior to DNS-based redirection for CDNs...

HTTP redirections add latency, but thats not the big problem.

The big problem with a 302 or similar HTTP redirection is HTTP redirection to a different IP will require a different hostname.  

Thus for top level pages, user-visible URLs would become something like a235.www.mydomain.com, rather than www.mydomain.com, which pollutes bookmarks and reduces user experience.

Yet for the "invisible" items within a page (eg, images loaded from img.mydomain.com), which actually compose the bulk of the items and latency, there is no redirection mechanism that says "all items from host img.mydomain.com should be instead fetched from a251.img.mydomain.com".  

Thus instead this would require that the HTTP server dynamically rewrite all references to img.mydomain.com to be a251.img.mydomain.com, because redirecting individual components will eliminate the latency gains which most CDNs are concerned with.  (100ms better latency to the web server can easily translate to 1s or more improvements in page-load time since most browsers do NOT pipeline HTTP requests, making the process of fetching many small images a latency, not bandwidth limited, activity).

Thus in either case, having the ALTO service be queried for HTTP redirection is probably not a happy solution for CDN applications where latency is a concern, not because of ALTO's limitations but because of the limitations of HTTP's redirection semantics and/or the need to do page rewriting.  

To do the latency-centric CDN-type redirections cleanly in HTTP REQUIRES one of two NEW redirection semantics for HTTP (and therefore corresponding support in ALL browsers):

1)  "For current HOST, contact system Y", basically overriding the DNS lookup

2)  "For URL prefix X, rewrite the prefix as Y", basically providing a custom rewrite rule to the browser.

Rather, what would be better is a mapping from DNS IP (or EDNS-client-subnet if/when that gets deployed by 3rd party resolvers) -> probable host PID.  Thus rather than the HTTP server querying ALTO, it is the DNS authority servers for a domain that need to use ALTO, and therefore also need some rough mapping from DNS IP address to client IP region within ALTO.

This would also allow the easy use of the mechanism to any OTHER latency sensitive application, eg, choice of VPN tunnel endpoint, etc.

Yes, Paul Vixie and some others in the DNS community would SERIOUSLY object, but as this is effectively established practice already (its how almost all major CDN's operate), if ALTO is to be useful to new CDN-type systems, it should integrate into the mechanisms that CDNs actually are able to use.

On Jun 4, 2010, at 9:09 AM, Reinaldo Penno wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Jun 2010 23:12:32 -0400

Hello Nicholas,

Your feedback is greatly appreciated. I will incorporate your points in the
HTTP redirection section.

Originally our intention with 302 was targeted at streaming services. For
example, you visit YouTube and when you click on a Video Link you get 302
for the video alone (i.e., a single object). I think this needs to be
clarified.

I agree that a common use case going forward is where the DNS server queries
an ALTO Server. This is captured in sections 6.1 and 6.3. I believe they
need revisions for further clarification

> This would also allow the easy use of the mechanism to any OTHER latency
> sensitive application, eg, choice of VPN tunnel endpoint, etc.

This is a good point.

Thanks.

Reinaldo

On 6/4/10 9:44 AM, "Nicholas Weaver" <[email-masked]> wrote:

> Unforutately on the use-case, 302 redirections are often regarded as
> significantly inferior to DNS-based redirection for CDNs...
> 
> The big problem with a 302 or similar HTTP redirection is HTTP redirection to
> a different IP will require a different hostname.
> 
> Thus for top level pages, user-visible URLs would become something like
> a235.www.mydomain.com, rather than www.mydomain.com, which pollutes bookmarks
> and reduces user experience.
> 
> 
> Yet for the "invisible" items within a page (eg, images loaded from
> img.mydomain.com), which actually compose the bulk of the items and latency,
> there is no redirection mechanism that says "all items from host
> img.mydomain.com should be instead fetched from a251.img.mydomain.com".
> 
> Thus instead this would require that the HTTP server dynamically rewrite all
> references to img.mydomain.com to be a251.img.mydomain.com, because
> redirecting individual components will eliminate the latency gains which most
> CDNs are concerned with.  (100ms better latency to the web server can easily
> translate to 1s or more improvements in page-load time since most browsers do
> NOT pipeline HTTP requests, making the process of fetching many small images a
> latency, not bandwidth limited, activity).
> 
> 
> Thus in either case, having the ALTO service be queried for HTTP redirection
> is probably not a happy solution for CDN applications where latency is a
> concern, not because of ALTO's limitations but because of the limitations of
> HTTP's redirection semantics and/or the need to do page rewriting.
> 
> To do the latency-centric CDN-type redirections cleanly in HTTP REQUIRES one
> of two NEW redirection semantics for HTTP (and therefore corresponding support
> in ALL browsers):
> 
> Rather, what would be better is a mapping from DNS IP (or EDNS-client-subnet
> if/when that gets deployed by 3rd party resolvers) -> probable host PID.  Thus
> rather than the HTTP server querying ALTO, it is the DNS authority servers for
> a domain that need to use ALTO, and therefore also need some rough mapping
> from DNS IP address to client IP region within ALTO.
> 
> This would also allow the easy use of the mechanism to any OTHER latency
> sensitive application, eg, choice of VPN tunnel endpoint, etc.
> 
> 
> Yes, Paul Vixie and some others in the DNS community would SERIOUSLY object,
> but as this is effectively established practice already (its how almost all
> major CDN's operate), if ALTO is to be useful to new CDN-type systems, it
> should integrate into the mechanisms that CDNs actually are able to use.
> 
> 
> 
> 
>

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 16 Jun 2010 01:09:16 -0400

Nice draft and efforts on an important problem that is naturally in the 
scope of ALTO.

Here are some comments. Some points include some discussions with Xuan 
Zhang from Yale tonight. Sorry the comments are a bit long.

First, some high level comments:
======================
- I feel that it can be helpful to have a section to enumerate some key 
differences between a CDN setting and a (swarm) P2P setting. Such 
differences can drive part of the requirements.

As an example difference, we have that  P2P has smart, adaptive clients, 
and thus can have lower requirements on fault tolerance and load 
balancing. A peer can have a large number of neighbors, and will evolve 
the topology and load balance among this large set. On the other hand, 
in a CDN setting, the serving set to a client is much smaller, and the 
clients are assumed to be dumb, non-adaptive.

- I feel that it can be helpful to define the problem settings first 
before delving into technical branches (HTTP Redirect vs DNS redirect).  
The basic problem setting is that we have a client Host that needs to 
select among a set of CDN nodes {CDN_1, CDN_2, ..., CDN_K}. A 
fundamental challenge, I feel, is that ALTO info can be partial and 
"colored" (i.e., has a perspective). Thus, it can be helpful to discuss 
according to the perspective settings, instead of  more technical detail 
settings (HTTP Redirect vs DNS redirect). It can be helpful to solve two 
fundamental settings:

   (S1) Host H, {CDN_i}, and the network connecting them belong to a 
single entity. ALTO info is from this single entity. This is a 
relatively easy, useful setting.

   (S2) Host H belongs to ISP, and {CDN_i} belong to CSP. This setting 
can be much more complex, because there are two perspectives: 
C^ISP(H<->CDN_i) vs C^CSP(H <-> CDN_i). Or we could introduce a third 
perspective, for example, C(H <-> CDN_i) coming from a third measurement 
party.

- Since this is CDN, does it may make sense to demonstrate, as a use 
case, how ALTO info may be integrated into the system of a major CDN 
system? Let me try an Akmai-like DNS based system, according to my 
understanding from their patent several years ago. Anyone who knows 
better public info please correct/update me. Let's call this system A. 
In system A, the first step is to map src Host H to a serving region 
represented by a higher level DNS server. To achieve this mapping, we 
may do the following info:

Step 1: Mapping from src address H to SPID, a src PID (e.g., partitioned 
according to local DNS server)
  This mapping can be provided by ALTO Map, from an ALTO Server.

Step 2: Look up SPID in a cost map

            Region 1  Region 2 .......... Region K
SPID1
SPID2
...

After this look up, we identify the lowest cost/closest region 
(represented by RID).

   This mapping can be provided by ALTO Map, from an ALTO Server.

Step 3: For a distributed implementation, the system directs to the 
corresponding DNS server for the identified region. This map can be the 
format:
Region -> lower level DNS server.

This mapping may not be provided by ALTO.

Note that the three steps can be streamlined into single hash 
implementation.

At a lower level DNS server:

Offline computation (maybe with some online triggered load balancing 
update), using consistent hashing and bin packing, to compute the map:

Dest address (including the bucket/customer info as part of the 
destination name) -> a short list of CDN servers.

This map may not come from ALTO. But after the selection, there can be a 
fine-grained tuning according to source address (otherwise, why deep 
deployment, instead of clustering/data centers). The fine-tuning can use 
a local, fine-grained ALTO Map, but need to be careful to not break load 
balancing.

Some detailed comments:
==================
- Section 4: it can be helpful to clarify the setting: the wording 
implies a single ALTO Server, which I assume, by default, is giving the 
perspective from the CDN network. Section 4.4 touches upon this issue. 
Moving it a bit forward can be helpful.

- Section 4: " ... intercepts an HTTP GET request (1)": add a reference 
to Figure 1.

- First para below Figure 1: I do not understand why you need to 
disambiguate PIDs containing only hosts from PIDs containing CDN nodes. 
It may be helpful to elaborate more.

- First/second para below Figure 1: Why do you have to enforce only 
costs from host to CDN? As an example, Akamai streaming uses multiple 
levels of CDN nodes (Entry points, reflectors, Edge Servers). Knowing 
info between these inter-CDN nodes can be helpful when computing 
redirection.

- Second para below Figure 1: How to determine the CDN PID from the 
hostname (domain name) of a URL?
   Is this sentence trying to address the issue: "Therefore the IP 
addresses contained in the cost maps may need to be correlated to domain 
names a priori."? But this is still not fully clear yet. From the big 
picture, it seems that the process is: (1) map from URL to a list of IP 
addresses, and (2) look up in the Map for direction.

- Second para below Figure 1: For the last sentence, it can be helpful 
to make it clear that the selection algorithm can be quite flexible and 
customizable. For example, a standard algorithm I cover in my class 
(from Akamai patent application) is to use consistent hashing + bin packing.

- GAP-1: I have no problem adding PID attributes. But the motivation, in 
the context of the document, is not fully clear, as it is not made 
explicit later how it could be used (did I miss it? if so, it can be 
helpful to add a forward reference)

- top of page 7: "a appropriate" -> "an appropriate"

- top of page 7: "The issue of default cost if one of importance." if -> is?

- I like it that the document presents two approaches in Sections 4.3 
and 4.4 respectively. I feel that Section 4.3 is conceptually simpler. 
For Section 4.4, then there is the issue of converting application info 
(CDN node load) to ALTO info. You may be forced to fine-grained PIDs in 
order to distinguish different CDN servers; or you can use some 
averaging of load of servers at a given location and add to the ALTO 
costs; but this can be less effective in achieve load balancing. Also 
note that Section 4.4 will force the ALTO info to be application 
dependent during conversion.

- First para after Figure 3: why the recommendation of partition?

- Second/third para of Section 5: mixed use of Proxy and DNS Proxy.

- Section 6 and others: it may not be necessary to be limited to 
selection based on the cost of CDN outgoing traffic; in some settings, 
the selection can be based on incoming cost, for example, for UGN.

- Figure 5: note that a general case can be more complex: at P2Pi 
meeting, a major issue we were trying to address was that there can be 
multiple ISPs in between from a subscriber to CDN. I hope that the 
"flattening-of-the-Internet" makes this less a problem.

- GAP-6 and GAP-7: I am not sure there is a need for defining an 
explicit Border Router Attribute.

Richard

---

From: Jiang Zhu <[email-masked]>
Date: Wed, 16 Jun 2010 17:40:53 -0700

Hi, Nicholas and Reinaldo,

DNS redirect is very limited because the DNS server only got the host
portion of the whole URL. Sometimes, in order to redirect to the right
destination, the full FQDN will be needed. For example,
www.abc.com/foo.mov will be redirected to
cdn.west.comcast.com/abc.com/qt/foo.mov while
www.abc.com/bar.wmv will be redirected to
cdn.east.comcast.com/abc.com/wmv/bar.wmv.

Also, in most of browser implementation, the redirected URLs are not visible
to the end users, thus I don't think the issue Nicholas mentioned may be a
problem. On the contrary, it has been usual practice to use 302 redirects to
load balance the HTTP requests to different web servers. The 302 redirect is
part of the HTTP transaction and the bookmarks should remain as the original
URL.

Thanks

-Jiang

On Tue, Jun 15, 2010 at 8:12 PM, Reinaldo Penno <[email-masked]> wrote:

> > 2)  "For URL prefix X, rewrite the prefix as Y", basically providing a
> custom
> > rewrite rule to the browser.
> >
> >
> >