Subject: [Ieprep] AF for Elastic Traffic

From: "Beard, Cory" <[email-masked]>
Date: Mon, 29 Apr 2002 17:28:43 -0500

In Section 2.4.3 in Fred's draft, he talks about requirements for supporting elastic traffic.  He says, "Routers used in supporting bottleneck points in an IEPS service should therefore also support Assured Forwarding."
 
What other ways could a service provider provide an acceptable ieprep solution for web browsing (or other types of elastic applications that involve user interaction) without using AF?  Overprovisioning is one, as long as they can show that the overprovisioning will persist even in high traffic conditions after a disaster.  Anything else? None readily come to mind for me.
 
Do we have a clear dividing line when it comes to supporting interactive elastic traffic?  Either a provider heavily overprovisions and does not turn on diff-serv, or they use AF?
 
Cory Beard

---

From: Ian Brown <[email-masked]>
Date: Tue, 30 Apr 2002 00:58:37 +0100

>What other ways could a service provider provide an acceptable ieprep
>solution for web browsing (or other types of elastic applications that
>involve user interaction) without using AF?

I think that for web browsing, the most important service would be an
Akamai-style highly distributed caching of sites that a customer (such as
the US gov't) felt were important in an emergency. This would allow access
for that customer's users and also potentially the public, reducing to some
extent general congestion in the network.

But this obviously doesn't help as much if there is high congestion in an
emergency user's access network. And it would be nice if anycast could be
widely deployed to help in the case of severe congestion in an important web
site's provider network.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 30 Apr 2002 10:14:24 +0100

Ian,

I agree about the usefulness fo akamai-style distributed service
and re-directs.  however...

> widely deployed to help in the case of severe congestion in an important web

unless I've missed some recent developments, I have very small hopes for
Anycast in the wide area.  anycast amounts to the propagation of host
routes -- which could be argued as ok for intra-site/domain use, but
just won't fly (ie, horrible scaling) for inter-domain at the network
level ala BGP.

-ken

---

From: Fred Baker <[email-masked]>
Date: Tue, 30 Apr 2002 13:58:28 -0700

At 10:14 AM 4/30/2002 +0100, Ken Carlberg wrote:
>I have very small hopes for Anycast in the wide area.  anycast amounts to 
>the propagation of host
>routes -- which could be argued as ok for intra-site/domain use, but just 
>won't fly (ie, horrible scaling) for inter-domain at the network level ala BGP.

huh? you're perhaps unaware of it, but one of the DNS Roots has for a while 
run as an anycast service. Anycast works just fine.

Certainly we need a host address for each service offered in that way, 
which means some form of insertion into IGP routing in an ISP network. That 
could be propagated to a neighboring network, but in the general case I 
don't see that it would be. Rather, the service would co-locate and 
contract with SPs that it deems important, and even if the SP tried to 
export the address, his neighbors would be unlikely to trust him for it. So 
an SP is absolutely in control of his routing - it is what he has accepted 
a contract to carry.

I'm going to guess that some on the list are wondering what in the world 
anycast is, and how Akamai relates. If you already know or don't care, skip 
to the last couple of paragraphs.

We have the capability in DNS to offer multiple translations of a name - 
DNS resolution of  www.example.com might well get half a dozen addresses 
back, from which the end system is supposed to choose at random. What that 
means, of course, is that an end system might randomly choose the least 
advantageous one or the most advantageous one, and has no guidance in 
making that choice.

Another way to do the same is to select a single address, put that address 
on each of half a dozen systems, translate the name to the address, and 
then have a router in front of those various systems that claims to be the 
right router to get to that address. Standard internet routing will get you 
from where you are to the nearest of those systems - you always specify the 
same thing, and you always make the most advantageous choice. There are 
other issues; if you start a long session and routing changes midstream, 
suddenly you're talking to a different server, and it has no idea what 
you're talking about.

The best solution to that issue I have run across depends on "optimized 
routing" of "mobile IP". In Mobile IP, we use one address as a variety of 
name, send a message to where routing makes it appear to be, and have a 
system on route (called a home agent) intercept the message and tunnel it 
to the actual target. In the "optimized routing" variant of that, the 
target system replies from the address it is topologically located at (a 
temporary address appropriate to its temporary location) carrying the 
original address in its "Home Address Option". I claim that if we treat the 
anycast common address as a "home address", and have each instance of a 
server responding to the anycast address in fact reply from its topological 
address with the anycast address in the Home Address Option, we work around 
the robustness issues.

Akamai accomplishes the same result, but in a different way. When you 
download a web page that has been "Akamaized", the URLs in it are replaced 
with special URLs (called ARLs) that point towards Akamai. The Akamai 
system compares the source address of the name lookup to a map and replies 
with one of 13,000 addresses of servers out in the great wide world.

The net effect of each (no pun intended) is to minimize the round trip 
delay on a session by selecting the most accessible server, and to maximize 
available bandwidth by forcing different clients to access different 
servers. In so doing, Ian is proposing that this potentially moves traffic 
away from links carrying critical traffic, leaving capacity to be used by 
other traffic including the emergency traffic.

I will agree that maximizing capacity as compared to offered load, by 
whatever means (buying big links is helpful too), will help in carrying 
that traffic. The question before the house is: can we expect that there 
will therefore be no issue for elastic traffic? I submit that we cannot 
definitively say. If offered load suddenly jumps by 1-2 orders of 
magnitude, as happened on the access links of some media sites on 9/11, it 
is very reasonable to believe that one could run into a problem; those 
media sites certainly did. Some of those media outlets, BTW, were Akamized 
on that date, and some of which were not; for the Akamized servers, 
~.akamaitech.com was bottleneck as much as the other fellows servers were. 
The question becomes: in such a case, what decisions do we make, and how 
are they justified?

However, our experience to date (Kobe, 9/11, and so on) suggests that 
backbone capacity is not seriously at risk. The issues are in the access, 
and the access tends to be specific to the set of servers behind it. The 
fact that CNN and New York Times were effectively inaccessible for a major 
part of 9/11 has no bearing on whether AOL was able to run AIM inside their 
network - there were few if any network paths that were used by both. The 
important thing is: can we ensure that traffic requiring a certain class of 
service in fact gets what it needs from the servers and access paths that 
are critical to them? From my perspective,

  - overprovisioning is a standard practice, but it is possible for crisis 
loads to exceed
    predicted demand in access paths
  - AF allows you to identify substreams within a traffic stream and "do 
the right thing"
    with them in the access path, and
  - there are serious firewall and server issues that have to be dealt with 
as well.

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 30 Apr 2002 23:31:10 +0100

> run as an anycast service. Anycast works just fine.

right, a single instance of a single well known server works.  i won't
argue with that. 

> an SP is absolutely in control of his routing - it is what he has accepted 

ok, and this is a different model than i'm used to, though it does fall 
under the "ok for intra-site/domain use" as i mentioned earlier...ie, fine
for IGP routing.  but i can't see the Anycast address being propagated
via BGP routing, which was the bone of contention in my original note. 

i'm still pessimistic about the scaling of Anycast in the event that
it magically takes off and people/businesses try to use it to contract 
thousands of services to a select set of SP's deemed 'important'.  just 
call me a Doubting Thomas on this subject.

-ken