Subject: [v6ops] simplfying Happy Eyeballs further

From: "Dan Wing" <[email-masked]>
Date: Fri, 17 Jun 2011 17:25:51 -0700

Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the
feedback we have received is along the lines of:

  * simplify further
  * don't worry about sending excessive packets
  * prefer IPv6, unless it's failing "a lot"

To that end, there seem to be three approaches.  We would like
feedback on which direction to document:

After calling getaddrinfo(), v6ops needs to decide if we should:
    a. initiate two simultaneous connection attempts (first IPv6
       address and first IPv4 address).  Both connections can be used
       by HTTP.  Subsequent connections to that same hostname would
       use whichever address family connected quicker.
    b. initiate one connection attempt to the first address returned.
       If it isn't successful after NNN milliseconds, initiate a
       connection attempt to the first IPv4 address returned by
       getaddrinfo().  (This is what Chrome is doing.)
    c. initiate one connection attempt to the first address returned.
       If it isn't successful after NNN milliseconds, initiate a
       connection attempt to the next address returned by
       getaddrinfo().

To deal with cases where "IPv6 is failing a lot", we might consider
ways to pick a good initial "NNN" value.  For example, we might
use a default of 200-300ms, and also define a DHCPv6 option so 
the network could convey a different default.   This seems 
useful for all sorts of situations, most notably 3G wireless 
(which wouldn't use DHCPv6, but could use the same idea to
provide the same sort of information in IPCP or whatever it 
likes.)

We might also consider ways to automatically tune NNN up or 
down.  For example, if IPv6 connected successfully, we can
increase NNN.  If an IPv6 connection times out and IPv4 wins, 
we decrease NNN.  This is similar to what we are doing today
in Happy Eyeballs -00, -01, and -02.  But we would simplify
this from what is described in Happy Eyeballs today (which
has a Tolerance Interval and suchlike, based on previous
feedback).  

Any thoughts on the various ideas above?

-d

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Jun 2011 02:32:25 +0000

I think what you've proposed would work nicely.

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Jun 2011 12:53:43 +0930

Hi Dan,

On Fri, 17 Jun 2011 17:25:51 -0700

>        use whichever address family connected quicker.

I like this first option as it is using actual connection response
times as the metric for selection, rather than DNS response times. I
don't think a slow DNS response should prevent a fast IPv6 or IPv4
server being used.

How often would this selection be reset? Perhaps the same or
similar interval as PMTUD?

I'd also be curious what methods/mechanisms are used when there are
multiple IPv4 and/or IPv6 addresses supplied if the first
connection attempts fail. The goal of happy eyeballs would
suggest trying to connect to all addresses at once for the best chance
of connection success, but that probably would create too many
connection setups. Or maybe not - if somebody has put multiple
addresses in DNS, then high availability is a likely goal of theirs, so
it might not be unreasonable for clients to do everything they can to
achieve that goal too.

> Any thoughts on the various ideas above?

Regards,
Mark.

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Jun 2011 01:10:19 -0400

> I think what you've proposed would work nicely. 

Oh, the irony.   I read what you'd written as if it were a single proposal, rather than three alternatives, and somehow it made sense that way to me.   I will have to reread the proposal... Sorry for the bizarre Emily Latella comment.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 18 Jun 2011 19:19:06 +1000

>        connection attempt to the next address returned by

c. Is what I implemented with decreasing NNN on subsequent connection
attempts.  100 to 200ms make for a good initial NNN.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Sat, 18 Jun 2011 12:04:18 +0200

>       connection attempt to the next address returned by

I like what Chrome is doing because it is so simple. However, I'm a bit worried
that it may be too simple and that when it's deployed on a large scale we
wish we would have gone for something a bit more complex.

The other end of the scale is to have a system that keeps track of the 
performance of both IPv4 and IPv6 and uses that to set preferences and
timeouts dynamically. In the long run I prefer to have something like that.

>provide the same sort of information in IPCP or whatever it 

To me this sounds overly complex. A host is quite capable of computing that
value on its own.

>Any thoughts on the various ideas above?

I think that the main thing we should do is to figure out what any Happy
Eyeballs implementation should *not* do. Because, it will cause too much load
on the network or it will not result in the right user experience.

After that, any algorithms that we may come up with are just friendly advice
to implementors.

(Now that I'm playing a bit with my own HE implementation, I've become quite
enthusiastic about its potential. I never liked the destination selection
policies. I much prefer systems to configure themselves)

---

From: Erik Kline <[email-masked]>
Date: Sat, 18 Jun 2011 06:47:00 -0700

> policies. I much prefer systems to configure themselves)

Agreed that recommending connection performance techniques has the
potential to be much simpler and I think, more importantly, more
/future proof/ than things like destination selection have shown to
be, given how difficult it can be upgrade systems in the field.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jun 2011 01:53:46 +1200

I prefer

> a. initiate two simultaneous connection attempts 

or even three. Some studies we've done on SHIM6/REAP and MPTCP performance
suggest that probing up to 3 addresses in parallel doesn't create
a significant load but does improve the time to establish a connection.

Regards
   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 18 Jun 2011 07:46:54 -0700

> a significant load but does improve the time to establish a connection.

Just like cell phones that constantly turn off and on their data connections
to optimize battery life, but in turn wreck the network with a flood of
signalling to attach and detach.

Please no.

Some of us are thinking about cgn exit strategies, and these ipv4
connections will be enough noise that I cannot properly dimension the ramp
down.

Sorry, we cannot always engineer the system to optimize on just the user
experience and expect all the other elements to scale and perform well. I
know there may be some backoff mechanism and affinity, but this is a
slippery slope where implementers will look to "improve " on a good idea to
make their product look better. I do not look forward to my HE refrigerator
sending out simultaneous connections to upload my grocery list to the cloud.

Cb

> > Any thoughts on the various ideas above?
 On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <[email-masked]>

---

From: Martin Millnert <[email-masked]>
Date: Sat, 18 Jun 2011 19:29:42 +0200

Cameron,

On Sat, 2011-06-18 at 07:46 -0700, Cameron Byrne wrote:
> 
> On Jun 18, 2011 6:54 AM, "Brian E Carpenter"
> <[email-masked]> wrote:
> >
> > I prefer
> >
<snip>
> connections will be enough noise that I cannot properly dimension the
> ramp down.
> 
> Sorry, we cannot always engineer the system to optimize on just the
> user experience and expect all the other elements to scale and perform
> well. I know there may be some backoff mechanism and affinity, but
> this is a slippery slope where implementers will look to "improve " on
> a good idea to make their product look better. I do not look forward
> to my HE refrigerator sending out simultaneous connections to upload
> my grocery list to the cloud. 

I thought it is unavoidable that LSN/CGN implies significant state load.
And that the way out is per-connection-stateless IPv6 forwarding.
  Thus, if your HE refrigerator sits on a home LAN with IPv6-only, the
1-connection-per-AF factor will only result in 1 connection regardless.

User/usage-driven cost explosion of CGN and/or poor v4 user experience
is not a bad thing in and of itself IMO. That it may help provide the
necessary drivers for operators to more seriously push IPv6 is only a
side-effect of the state vs no-state cases of v4/v6.
  It's a flaw of NAT to me -- the real limits of
multiple-connection-attempts/connection ought to come from the
end-hosts, not the transport / internet layer itself (if they do
something is wrong and should gracefully be fixed).

Telco networks with a O(10) to O(100) unnecessary/necessary
boxes/elements ratio (ie., the signaling/state costs you speak of)
shouldn't stop a positive evolution of the internet protocols as a whole
IMO:  Remove the unnecessary elements instead. :)  (gosh)
  We shouldn't optimize after the poorest designs, where 'good design'
=== #boxes -> 0.

Kind Regards,
Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jun 2011 05:53:34 +1200

> signalling to attach and detach.

I agree that flooding is not ideal from an operator's PoV. However, the users'
PoV matters too, and assuming the results are cached for a reasonable length of
time, I seriously doubt that the negative effect will be significant. (Once MPTCP
gets deployed, this will happen anyway, since it always uses multiple addresses.)

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 18 Jun 2011 11:18:17 -0700

> I thought it is unavoidable that LSN/CGN implies significant state load.

Yes.  CGN does imply high load, and anyone who operates such a high
load system will look for as many ways as possible to reduce said
load.  For example, many folks in the CGN space are interested in
limiting the amount of CGN capacity a given subscriber can consume
(who would need more than 20 simultaneous connections ? :) )

> And that the way out is per-connection-stateless IPv6 forwarding.

We can refer to this as network nirvana.  Not there yet.

> 1-connection-per-AF factor will only result in 1 connection regardless.

HE + IPv6-only?  Why bother with the HE, right?  Let's assume my
tablet, phone, computer, and refrigerator all run Skype and therefore
require IPv4.

>  We shouldn't optimize after the poorest designs, where 'good design'

My only point is that we should have more carrots for IPv6 usage
(virtuous cycle of more clients, connections, peering, bw, features,
AF agnostic apps ...) and without creating unneeded sticks for IPv4
(further hobbling and overloading the CGN...)

I think HE is very good carrot delivery mechanism, but in the wrong
hands it can add sticks (hindrances to IPv4 adoption).

Let's keep in mind HE exists for the purpose of improving user
experience over what it is today.  That is already somewhat achieved
Chrome's pre-HE implementation.  Let's not "love HE to death"  so that
we take it from making IPv6 (dual-stack) easier to making it so that
IPv6 is harder.

CB

---

From: Teemu Savolainen <[email-masked]>
Date: Mon, 20 Jun 2011 15:53:04 +0300

Is the getaddrinfo the lowest sofware layer where we can go to? I mean
eyeballs could be happier if the possible issues related to A and AAAA
queries were included in the algorithm. It is simpler to work only after
getaddrinfo has returned with both IPv4 and IPv6 addresses, but better
results could be obtained if application would use API to issue separate
queries for IPv4 and IPv6 addresses, and include the DNS delay in the
address family selection (e.g. not wait for another DNS resolution more than
YYY milliseconds after first completes).

About DHCPv6 and 3G: DHCPv6 has been supported for parameter configuration
for a long time, and hence this value could be delivered also in 3G with
DHCPv6 if so chosen.

I don't like a) due to waste I consider excess, so something that prefers
IPv6 when it should work and just does very quick fallback to IPv4. So that
most of the time only IPv6 connection would be created. I guess if IPv6
sometimes is delayed, it would not matter too much of IPv4 connection
attempt would be launched slightly before IPv6 connection has completed.

Best regards,

Teemu

2011/6/18 Dan Wing <[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 20 Jun 2011 23:44:57 +1000

In message <[email-masked]>, Teemu Savolain
> YYY milliseconds after first completes).

DNS response time has absolutely nothing to do with which address family
is best to use.

> --0015174beb6a6005ab04a62437a7
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> Is the getaddrinfo the lowest sofware layer where we can go to? I mean eyeb=
> alls could be happier if the possible issues related to A and AAAA queries =
> were included in the algorithm. It is simpler to work only after getaddrinf=
> o has returned with both IPv4 and IPv6 addresses, but better results could =
> be obtained if application would use API to issue separate queries for IPv4=
>  and IPv6 addresses, and include the DNS delay in the address family select=
> ion (e.g. not wait for another DNS resolution more than YYY milliseconds af=
> ter first completes).<br>
> <br>About DHCPv6 and 3G: DHCPv6 has been supported for parameter configurat=
> ion for a long time, and hence this value could be delivered also in 3G wit=
> h DHCPv6 if so chosen.<br><br>I don&#39;t like a) due to waste I consider e=
> xcess, so something that prefers IPv6 when it should work and just does ver=
> y quick fallback to IPv4. So that most of the time only IPv6 connection wou=
> ld be created. I guess if IPv6 sometimes is delayed, it would not matter to=
> o much of IPv4 connection attempt would be launched slightly before IPv6 co=
> nnection has completed.<br>
> <br>Best regards,<br><br>Teemu<br><br><div class=3D"gmail_quote">2011/6/18 =
> Dan Wing <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">dwing@cis=
> co.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:=
>  0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
> : 1ex;">
> Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the<br>
> feedback we have received is along the lines of:<br>
> <br>
>  =A0* simplify further<br>
>  =A0* don&#39;t worry about sending excessive packets<br>
>  =A0* prefer IPv6, unless it&#39;s failing &quot;a lot&quot;<br>
> <br>
> To that end, there seem to be three approaches. =A0We would like<br>
> feedback on which direction to document:<br>
> <br>
> After calling getaddrinfo(), v6ops needs to decide if we should:<br>
>  =A0 =A0a. initiate two simultaneous connection attempts (first IPv6<br>
>  =A0 =A0 =A0 address and first IPv4 address). =A0Both connections can be us=
> ed<br>
>  =A0 =A0 =A0 by HTTP. =A0Subsequent connections to that same hostname would=
> <br>
>  =A0 =A0 =A0 use whichever address family connected quicker.<br>
>  =A0 =A0b. initiate one connection attempt to the first address returned.<b=
> r>
>  =A0 =A0 =A0 If it isn&#39;t successful after NNN milliseconds, initiate a<=
> br>
>  =A0 =A0 =A0 connection attempt to the first IPv4 address returned by<br>
>  =A0 =A0 =A0 getaddrinfo(). =A0(This is what Chrome is doing.)<br>
>  =A0 =A0c. initiate one connection attempt to the first address returned.<b=
> r>
>  =A0 =A0 =A0 If it isn&#39;t successful after NNN milliseconds, initiate a<=
> br>
>  =A0 =A0 =A0 connection attempt to the next address returned by<br>
>  =A0 =A0 =A0 getaddrinfo().<br>
> <br>
> To deal with cases where &quot;IPv6 is failing a lot&quot;, we might consid=
> er<br>
> ways to pick a good initial &quot;NNN&quot; value. =A0For example, we might=
> <br>
> use a default of 200-300ms, and also define a DHCPv6 option so<br>
> the network could convey a different default. =A0 This seems<br>
> useful for all sorts of situations, most notably 3G wireless<br>
> (which wouldn&#39;t use DHCPv6, but could use the same idea to<br>
> provide the same sort of information in IPCP or whatever it<br>
> likes.)<br>
> <br>
> We might also consider ways to automatically tune NNN up or<br>
> down. =A0For example, if IPv6 connected successfully, we can<br>
> increase NNN. =A0If an IPv6 connection times out and IPv4 wins,<br>
> we decrease NNN. =A0This is similar to what we are doing today<br>
> in Happy Eyeballs -00, -01, and -02. =A0But we would simplify<br>
> this from what is described in Happy Eyeballs today (which<br>
> has a Tolerance Interval and suchlike, based on previous<br>
> feedback).<br>
> <br>
> <br>
> Any thoughts on the various ideas above?<br>
> <br>
> -d<br>
> <br>
> <br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">h=
> ttps://www.ietf.org/mailman/listinfo/v6ops</a><br>
> </blockquote></div><br>
> 
> --0015174beb6a6005ab04a62437a7--
> 
> --===============2809441630508197365==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============2809441630508197365==--

---

From: Gert Doering <[email-masked]>
Date: Mon, 20 Jun 2011 15:47:36 +0200

Hi,

> DNS response time has absolutely nothing to do with which address family

Theoretically true, but in the face of broken auth servers that just 
ignore AAAA queries (= no response, resolver timeout -> delay) and other 
weirdness, for a *happy eyeball* it might be a good plan to try the first 
address family as soon as the DNS response is there.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Jun 2011 00:30:59 +1000

> address family as soon as the DNS response is there.

Servers which ignore AAAA queries basically disappeared from the
network several years ago.  There are the odd ones about but they
are hard to find even when looking for them.

There are servers that respond with incorrect negative responses
but most of them look like configuration errors.  A misconfigured
full server behind a load balancing front end or parking site trying
to use a parent zone to answer zones that have been delegated to
it.

Registries, if they were meeting their RFC 1034 requirements, would
clean up the latter.  They can only operate where the TLD doesn't
perform sanity checks at delegation time.

Also it is not hard to get nameservers that work.  If a site is
slow because they are running broken nameservers should we let them
off the hook.  Perhaps having customers complain that their site
is slow will get them to fix their end.

I complained to Verisign about WWW.VERISIGNINC.COM not working over
IPv6 (PMTUD broken) and it was fixed within 24 hours.  Sometimes
the correct thing is to complain.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Mon, 20 Jun 2011 17:16:55 +0200

>YYY milliseconds after first completes).

I think that for that you would need an asynchronous DNS (stub) resolver. They
exist, but I think don't there is anything close a standard API at the
moment.  (Multi-threading would be another option, but I don't want to
go there)

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 20 Jun 2011 08:43:52 -0700

> moment.  (Multi-threading would be another option, but I don't want to

rewiring the behavior of DNS resolvers seems like a bridge too far esp given how little it's likely to tell you about the path between you and the host you're going to subsequently attempt to connect to.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jun 2011 11:47:47 -0400

On 2011-06-20 11:43, Joel Jaeggli wrote:
> rewiring the behavior of DNS resolvers seems like a bridge too far

It's been available in multiple open source libraries since quite some 
time. One example is the venerable libevent.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 20 Jun 2011 08:51:22 -0700

On Jun 20, 2011, at 8:47 AM, Simon Perreault wrote:

> It's been available in multiple open source libraries since quite some time. One example is the venerable libevent.

so hypothetically I ask my upstream resolver for www.google.com seperately for A and AAAA I do this over ipv4, both results are cached so they're delivered in more or less the same amount of time, what to I conclude from that?

does the search list in your resolv.conf further amplify the number of queries you've got to make?

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jun 2011 13:32:52 -0400

On 2011-06-20 11:51, Joel Jaeggli wrote:
> so hypothetically I ask my upstream resolver for www.google.com
> seperately for A and AAAA I do this over ipv4, both results are
> cached so they're delivered in more or less the same amount of time,
> what to I conclude from that?

Nothing. You don't make parallel DNS queries in order to conclude
anything about the remote host. You make parallel queries to avoid
delays when e.g. a DNS server doesn't reply to AAAA queries.

It's a way to include the DNS process in the overall connection
establishment process. IIRC there was a graph like this in an IAB
presentation by Stuart Cheshire a few IETFs ago:

         +----DNS A------TCP SYN-----[finish]
       v4|
[start]--+
       v6|
         +----DNS AAAA---TCP SYN-----[finish]

> of queries you've got to make?

Personally, I'd rather run a lightweight caching nameserver (e.g.
Unbound) locally and let it handle upstream server failures.
http://www.unbound.net/documentation/info_timeout.html

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Michael Newbery <[email-masked]>
Date: Tue, 21 Jun 2011 14:57:25 +1200

On 19/06/2011, at 2:46 AM, Cameron Byrne wrote:

> 
> On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <[email-masked]> wrote:
> >
> > I prefer
> >
> Just like cell phones that constantly turn off and on their data connections to optimize battery life, but in turn wreck the network with a flood of signalling to attach and detach.
> 
> Please no.
> 
> Some of us are thinking about cgn exit strategies, and these ipv4 connections will be enough noise that I cannot properly dimension the ramp down.
> 
> Sorry, we cannot always engineer the system to optimize on just the user experience and expect all the other elements to scale and perform well. I know there may be some backoff mechanism and affinity, but this is a slippery slope where implementers will look to "improve " on a good idea to make their product look better. I do not look forward to my HE refrigerator sending out simultaneous connections to upload my grocery list to the cloud.
> 

Given that Google Maps and iTunes already attempt 150+ simultaneous connections, does three rather than two happy-eyballs attempts really matter? 

Actually, thinking about it, this presents an interesting problem to happy eyeballs. Since most modern browsers attempt to parallelise requests, and many of these parallel requests are to the same IP address, what is the best approach? Should the browser attempt a SINGLE happy eyeballs connection attempt, PER HOST, and then go parallel once the connection result is known; or should it launch happy eyeballs simultaneously on every session.

The former strategy negates some of the user benefits, as the bulk of the parallel transfers are delayed while they first session connection per host is established; the second makes for an, arguably, overly chatty host (and upsets LSNs---which some might consider an upside :) ). The former could be tricky to code; the latter may be resource heavy for things like smart phones.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 20 Jun 2011 20:47:18 -0700

> Actually, thinking about it, this presents an interesting problem to happy eyeballs. Since most modern browsers attempt to parallelise requests, and many of these parallel requests are to the same…

A modern desktop pc can as a server, maintain thousands of simultaneous tcp connections without much effort. the $49.95 nat box you bought with 16MB of ram not so much, the $.5 million dollar firewall cluster someone might deploy to do LSN has a distinct incentive to minimize the number of connections per user... In some sense the ability to reap some connections quickly is nice but stateful inspection devices are limited by the number of new connections per second as well as the size of the total number of connections.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Jun 2011 10:33:03 +0200

In your letter dated Tue, 21 Jun 2011 14:57:25 +1200 you wrote:
>Actually, thinking about it, this presents an interesting problem to 
>happy eyeballs. Since most modern browsers attempt to parallelise 
>requests, and many of these parallel requests are to the same IP 
>address, what is the best approach? Should the browser attempt a SINGLE 
>happy eyeballs connection attempt, PER HOST, and then go parallel once 
>the connection result is known; or should it launch happy eyeballs 
>simultaneously on every session.

I don't think this is a big problem. HE keeps track of how long it normally
takes to set up a connection. There will be no extra overhead as long as the
timeout is long enough that most connects succeed within the timeout. So
it is only particularly far or slow servers that cause extra connections to
be set up.

This may have an impact on already overloaded servers. So the
'slashdot effect' may get worse.