>> Albert Greenberg: Okay. So it's a great pleasure to introduce Damon Wischik who is
visiting from University College London. Damon is a research fellow of the Royal
Society. Is that right?
>> Damon Wischik: I have a research fellowship from the Royal Society.
>> Albert Greenberg: Okay. A research fellowship from the Royal Society and he's
working on IP and Ethernet congestion control, modeling, networking, multipath routing,
buffering and switches, p2p networks as well. And today he's going to give us an
interesting talk about short messages.
>> Damon Wischik: Thanks. Thank you for the invitation to speak. I'm just going to
start off with a few quick slides.
>> Albert Greenberg: Oh, Damon, tell folks when you'll be around to follow up.
>> Damon Wischik: I'll be around Tuesday through Friday of next week, and it will be
great to talk with people in those times.
I'll start by saying a little bit about -- first of all, introduce myself and the great UCL
Networks Group, and these are the four people in it: There's Mark Handley, who's been
around Internet protocol design for a long time; Kyle Jamieson, who's just arrived from
MIT; Brad Karp, who works in distributed systems, previously from Carnegie Mellon
and Intel; and me, and I come from a math background and it's a bit of an adventure
seeing what computer scientists work like, think like.
I'm going to talk about short messages, but I just wanted to have a few quick slides
saying what other things I work on in case those triggers any interest. First question was
queuing theory for TCP. The question which I've listed up here, how big should buffers
be in core Internet routers, it's a strange question. There are several different answers
which differ by odds of magnitude. Cisco builds in roughly 4 gigabytes of memory,
which may not sound like a lot, but is terribly fast memory, so massively expensive, very
hard to get right.
There was an exciting paper several years ago by Nick McKeown from Stanford who
said, no, hold on, that's crazy, you only need 40 megabytes. And actually I think the
answer is you only need 30 kilobytes in Internet routers, no matter how big they are.
This is clearly not an engineering question; this is a math question to try an get right, or
the magnitude scaling phenomena.
And so the answer to this question, how big should routers be, you need to bring in Kuhn
theory and you need to understand stuff about synchronization and so on. A
long-standing question is about TCP. So this topic one, I won't speak about.
>>: Did this have impact? Did people starting buying smaller memories? What did this
lead to?
>> Damon Wischik: I don't think the Internet router people really have done anything.
There's no point in them because Cisco and Juniper have worked out how to do very big
memories. That acts as a very good barrier to entry for smaller companies to come in.
So Cisco and Juniper are happy with the status quo.
The companies who actually want to do stuff, they use like Ethernet switches, which just
have small buffers in anyway, and BT's 21st Century Network, they've configured the
buffers to be small because they've worked out that's what you need for good
performance. So it's something that people are doing, but no one's really acknowledged
it. I think that's the status.
Topic two I won't be talking about, is scheduling in switch networks. A switch
network -- I've got a picture of a roundabout here. A roundabout, there are four traffic -four roads coming in, so twelve possible traffic flows. There may be customers from the
south who want to go north, from the north who want to go east and so on.
And the scheduling problem is who -- which cars get to flow through the system when.
And so with Devavrat Shah from MIT, we've worked out the queuing theory behind this,
and this leads to ideas about what the best way to schedule it should be.
It's a very general model. We've applied it specifically to input queued switches in
Internet routers. It's the same sort of model to describe [inaudible] roundabouts. It's the
same sort of model to describe locks in databases. So it's an interesting thing which
will -- which I hope will go further.
Another piece of work, this is more Internet architecture stuff than math, what we call the
resource pooling principle. The idea of resource pooling is if you have a network with a
whole bunch of things with capacities, you want them all to behave like a unified whole.
You don't have to want to have to worry about, well, I have this much memory here, this
much processing there, this much bandwidth here. You want them all to behave as
though they lump together; in other words, you want to achieve resource pooling.
Resource pooling is the only way to achieve a reliable network. Telephone networks
have implemented it from I guess the early '80s. It's the only way to achieve reliable
service on cheap hardware. It's so useful that everyone who's discovered it sort of
independently, like AT&T and [inaudible] have it in their phone networks. Enterprises
have multihoming of their sites. That's a form of resource pooling. Peer-to-peer
networking is also trying to pull up the capacity. Even now with [inaudible] packet
switching, the core architecture principle of the Internet is a type of resource pooling.
You're trying to make better use of the bandwidth, trying to share all the capacity of a
link.
And everyone's built in different mechanisms, and they all clash horribly, especially the
BGP traffic engineering type mechanisms. And we believe that multipath routing, if you
give the end systems, the TCP systems the ability to split the traffic over multiple routes,
then it will get virtually all the benefits of resource pooling that everyone's looking for.
But that's the beginning of a research agenda. There aren't really any definite results
here, but it's an exciting area.
Okay. So I'm not going to talk about those three things. But if there's anyone who would
like to talk to me afterwards or ask questions, I'd love to.
>>: I'm just wondering if the [inaudible] TCP holds true for short messages?
>> Damon Wischik: Short messages would benefit from multipath, and I'll get to that
later on.
Okay. So now the actual talk: Short Messages. And there's a paper up on this -- my
Web site.
This is an outline of the talk. I'll go around in a circle and end up roughly where I started.
I'll start off talking about networked applications. The networked applications basically
work -- it seems to me, the way I use computers, at any rate, is no one cares about how
fast an individual computer is. All computers work lightning fast compared to what you
actually do with them. What you actually do with them is you access things over
network, and it's accessing things over network which is the real bottleneck, and that's the
thing we need to get right to have good responsiveness for computer systems.
So I'll talk about, first of all, sorts of -- some very simple sorts of network applications
that we might think about.
To understand what's going on there, we need to look at what type of network they're
running over. So then I'll talk a bit about network theory, network modeling, traffic
modeling. And based on these ideas, I'll then move on to distributed algorithms, which
will be a more formal way of expressing these classes of problems. And then I'll go back
and end up where I started and think a little bit about particular suggestions for
networked applications.
All right. So this is where I'm starting.
Here's an example of the most canonical networked application, just a Web browser.
And what I'm doing here is I'm going to a particular Web site, Slashdot. This was
motivated by frustration, basically, this talk, sitting in a -- it was a hotel room in Stanford
where I reliably got roundtrip times of between 2.5 and 3.5 seconds. I couldn't work out
what sort of networking stuff might be going on there, but it was really, really horrible
performance.
There's a comment here by Mark Handley. He's the guru of UCL networking. He said:
In a perfect network, all transfers should complete in one roundtrip time. That's
obviously the best you can ever hope to achieve.
So let's see what actually happens when you go to Slashdot. Type in the URL. Waiting.
Waiting. Transferring data. That's a good sign. Waiting for images. Waiting. Oh,
we've got something. Waiting for ads from Google. More waiting for ads from Google.
Waiting for ads from DoubleClick. Waiting for -- I guess this is some sort of tracking
[inaudible] tracking. [inaudible] images. The next one's very important. I think it's
giving us the rounded corners. Waiting for Google's Web service tracking. And now
we're finally done.
So it's not one roundtrip time. It's stupid that Web users have somehow become
conditioned to live with five-second delays, six-, ten-second delays in just retrieving a
Web page. I don't understand why it is at all. I don't see why anyone should have to wait
more than a few hundred milliseconds, but we do. We just put up with it.
This is a really nice visualization. It's called Firebug. I'm sure several people here have
tried it. It keeps tack of all the different pieces that are loaded and it tells you when the
download started and how long it took.
One thing which is interesting here is that the time it takes to download an item has
virtually no relationship at all to the size. Those 37 kilobytes took 1.83 seconds; 62 took
5.82 seconds; and 4 kilobytes, under a second; 21 kilobytes in 300 milliseconds.
Basically there's no relationship at all between file size and how long it takes to download
it. But that's a sightly silly thing to say about networks. But it's just true for the
performance of these things, bandwidth is simply not an issue at all.
Here's another example ->>: [inaudible]?
>> Damon Wischik: [inaudible] is -- well, the latencies come in several ways. There's
the latency of propagation delay, just how long it takes like to get the serialization delays.
There's delays due to message drops and timeouts. And then there's delays of the server
at the far end. I'll be talking much more specifically about some of the network-related
drops. I won't be talking about the latencies caused at the back end.
Here's another example I looked at. This is if I log on to Hotmail, from the instant I click
on "log in" on Hotmail, what has to happen? Well, first of all it goes to retrieve this
thing. This is a secure item. That tells it to retrieve this item, which tells it to retrieve
this item, which tells it to retrieve this, which tells it to retrieve these, which tells it to dot,
dot, dot, and it goes down here. So just to get your inbox, there's an awful lot of
backwards and forth, to and fros.
And what's more, some of these are structured in sequence. I mean, this thing tells you to
retrieve this which tells you to retrieve this. And so just the height of this tree gives you a
bare minimum number of roundtrip times before we get to see the inbox.
One thing I found really, really bizarre here is I had always been taught that reliable
delivery is something which TCP does and that TCP sends the packet, it waits for an
acknowledgment. If it doesn't get the acknowledgment, it will resend the packet. And so
you retrieve reliable delivery through TCP.
But that's not what this does. This has reliable delivery in JavaScript. So the JavaScript
sits there and it sends an http request. But if the answer doesn't come back in time, it will
send another http request. And I marked out those items with a bold border. And I can't
work out any rhyme or reason behind why some of it so reliably delivered into other bits.
So why is it that Windows Live wanted to protect this and this and this and this but not
some of the others.
Anyway, I don't know what the answer is at all there, but it's -- at least it's telling us
something. The fact that people are forced to get reliable delivery in JavaScript in the
body of the Web pages says I think that there's something wrong with the way we think
about reliable delivery and the way it's layered in the stack.
Here's another example. This is from Google. This is what their Web page used to look
like until December last year. They have a much longer, taller tree there. They switched
it in December last year because they did a whole bunch of rewriting their code, and in
particular they rewrote their Web stuff to make it load faster, and they ended up with a
slightly flatter system here.
Again, I really have no idea what the software engineering is behind the structure of this.
I've only looked at the behavior of my Web browser to try and track what they're doing.
Okay. So let's look a little bit in more detail at some of these. Let's say to retrieve a
single one of these items, what needs to happen. Sorry. Before I go on to an example, I'll
try and say something a bit more abstract, abstract problem statement.
A network transaction. These are all examples of what I will call a network transaction.
I'm not trying to fit into any established literature here, but this is just a convenient one.
A network transaction is the coordinated exchange of short messages between computers
on an unreliable network.
The example I've given here, reliably retrieving the Web page. Other examples might be
just reliably delivering a message along a path in a network or electing a leader in an ad
hoc network or sharing state between players in an online game.
So network transactions, that's basically what I mean by short messages, by the title of
the talk.
I didn't say what the file sizes were in those Web page examples. They're all very short.
None of those items -- none of the 60 items which Gmail downloads are more than a few
kilobytes big.
So right now I'm going to drill down into some of them. To retrieve a single one of those
items, there's a dialogue which goes in. The client says hello. The server replies hello.
Client says, okay, please send me the data. Server says, okay, here's the data, good-bye,
and client says good-bye. This is what just if you have http running over TCP, this is the
exchange of messages need to retrieve a single one of these items. Nine packets in total.
Two roundtrip times until the client hears the answer.
All right. So what does TCP do to -- behind the scenes to cope with the fact that the
Internet is unreliable? It does reliable delivery. Let's say the client here -- it sends the
hello message, and if it doesn't receive an answer back within a certain timeout period, it
will resend the message. The trouble is that these retransmits can be very, very slow.
And the standard is that the retransmit time is three seconds for the first packet in the
sequence of messages. So if you think with that, that's a Microsoft example, it's got 45
items to retrieve. Each item has one, two, three, four messages which need to happen.
That's an awful lot of messages where there can be drops. If there's a drop, you can lose
an awful lot of time from the user point of view. And the larger the Web page, the more
complicated it is, the more the problem.
So this timeout rule, this is what TCP does for short messages. It has a different
retransmit mechanism which kicks in when you have large things to transfer.
>>: What is RTO?
>> Damon Wischik: RTO, they call it retransmit timeout. That's what it stands for. So
you just send it. You wait and RTO. And if you don't get it within a timeout period, you
resend it.
And each side -- each side in the communication uses its own RTO timer and it updates
it. It tries to get RTO equal to roundtrip time, because that's the plausible thing for it to
do. But for short messages there's no time, so it just uses a very large timeout value to
start off with.
So basically a time out is a real killer, and complicated Web transfers, you're very likely
to be killed.
>>: On your first packet, is that the data packet or is that like the SYN, SYN/ACK
[inaudible]?
>> Damon Wischik: That's the SYN, SYN/ACK.
>>: Is there any kind of analysis how [inaudible] timeouts are in a typical transfer?
>> Damon Wischik: Yes. Here's the paper from people in Cambridge Computer Lab:
"The Effect of Early Packet Loss on Web Page Download Times." So they look
specifically to this question. It was a measurement study in the field, so they were
looking at what it was back in 2003.
>>: How did they did they do that [inaudible]?
>> Damon Wischik: They inserted a probe in the campus network and the probe did -- it
looked at the IP packets, then it looked at TPC, then it reassembled the http request
inside. And so it produced a -- you stick a probe somewhere in the network and it
produces a complete picture of what the Web pages that they used was downloading
were. It's a really nice visualization tool.
So you can look at a problem and then drill down and see which particular packets caused
the problem. That system was called N Probe or X Probe or Star Probe or -- I think they
changed its name several times.
>>: So the packet [inaudible] less popular servers or major Web servers ->> Damon Wischik: Sorry, could you repeat the question?
>>: So on a short Web page, you would -- the same timeout is probably what hurts you
the most, right? [inaudible] I'm just curious if these people saw same timeouts in this
paper [inaudible] less popular Web servers or major Web servers or --
>> Damon Wischik: I don't think it's a question of who the Web servers are; it's really a
question of what your network provider's like. And in the UK, at any rate, the serious
problems would be at the link from the core to your local exchange. I think if you're a
U.S. cable subscriber, the problem will be the uplink from you to your base station. I
think basically the problems will be caused by your network provider, not by the Web
server.
>>: [inaudible].
>>: It's usually not [inaudible].
>>: The only reason I was asking this is because I don't remember the exact paper, but
there was [inaudible] less popular Web servers actually have poorer connections to the
network [inaudible] causes the problem, it's the Web server's link to the [inaudible]
hosting provider somewhere [inaudible].
>>: [inaudible] could imagine that my wireless router, have it noisy when I was
[inaudible] whole bunch of stuff that a consumer network [inaudible] not reliable
[inaudible].
>> Damon Wischik: For a long time in the UK, it was the transatlantic link to the U.S.
which was the severe bottleneck. I think basically the hot spot moves around the Internet
and there are cycles and it's very hard to know precisely where it will be.
>>: So is there a difference between rate of first SYN drops versus other -- than data
packet drops?
>> Damon Wischik: I don't have the data. I'm sure there is. But I don't know any data
points,
>>: The network would just be forwarding packets or [inaudible] in a row. Trying to
figure out why it would drop the first SYN more so than when dropping a packet.
>>: It doesn't.
>> Damon Wischik: I wouldn't expect -- so the question is should it be the same packet
drop probability for SYNers, for a data packet. I would guess it's possibly the same,
possibly it -- the network has mechanisms to give priority to SYNs. I think that's
unlikely.
>>: The only reason I can think of, especially wireless things, is that SYN packets are
smaller. So there is a very, very small problem in that SYN packets [inaudible]
experience less loss than data packets. But that's all minor details.
>> Damon Wischik: Yeah. I think that's very negligible.
>>: Yeah, I was just wondering, I'm curious, I was trying to track on what you were
saying. Thank you.
>>: Any major conclusions from this paper [inaudible]?
>> Damon Wischik: No. I mean, that it's a problem. That this is the serious component
of poor quality of service for users. But that's all they concluded really.
This is an example of a more complicated network transaction. This is an https thing,
where you say hello, hello, let's use this cipher. Okay. Here's my public key. Okay,
here's a secret key for the data. Okay. And now the client can send its request. So like
Google, the very first two things are secure things -- secure items, and those have an
awful lot of to and fros.
Here's another example. This is if you do a directory listing in Windows, as far as I can
tell. I don't know if there's anyone here who can correct me. This is the way it works.
You send a message saying find the first file in a directory. It replies with the first file.
And you tell it find next file, and it replies. And so to do a directory listing of a large
directory, you're exposing yourself to all sorts of problems here.
So why are they programmed like this? It seems to me that from a naive networking
person point of view, that you might as well just send the request and the thing should
prepare the entire answer and send it to you in one great big chunk. Why doesn't it do
that? I don't know.
Here are some guesses. First guess, the programmers just want to get a working, bug-free
version out there quickly and so they're not so concerned about network performance.
Guess two, that these are examples of lovely, elegant modular code. And maybe it's split
into development teams working on different features and they split it up in this way
because it's the most natural way to split up their Web pages.
My third guess, which I was disabused of last week, was that programmers, for example,
here at Microsoft, have wonderfully fast campus systems where everything works
perfectly and so they're not aware of how bad it will be when things don't start working. I
learned that's not actually the case.
So these are my guesses. I really wouldn't need to work out why people -- I'd need to talk
to someone like this to find out why they're actual programming ->>: [inaudible] from the network side, you've seen the last one, fairly common where all
of a sudden you get 120 milliseconds from [inaudible] and it just blows up an application.
>> Damon Wischik: It happens.
>>: Doesn't happen as often with the others.
>> Damon Wischik: Okay. So I've said a bit about the sorts of problems that I'm
interested in looking at. And now I'm going to talk about -- well, obviously, the behavior
of these things depends on the network, so now I'll say a bit about what we need to know
about the network.
Here's the most basic thing: mice and elephants. This by now is a very old story from
early 1990s. Walter Willinger from AT&T and groups of other researchers, they
discovered this phenomenon. Most traffic on the Internet is composed of large traffic
flows, which are called elephants. Nowadays think of an elephant as being a
high-definition movie download. And yet most network tasks are made up of very short
flows, which are called mice. Mice are tiny, like one packet big, five packets big, and
they're very, very numerous; there are way more mice than elephants.
>>: Sorry, how do you -- I feel like that's [inaudible] in most traffic, volumewise it's
mostly elephants?
>> Damon Wischik: Volumewise it's -- most bytes are from elephants. Most flows are
from mice.
Here's I guess the definitive early measurement study by Crovella and others. There are
various theories about why this happens. These people, John Doyle and Carlson, argued
that mice and elephants arises because it's the optimal way to split up your data. If you
have a user who's doing queries, first of all, they want a quick look at the table of
contents and that will enable them to make a quick decision, and then if that's not enough,
then they'll go and look at something larger which will enable them to make a further
decision and go on to something else. So they have an argument about optimal
partitioning of data which said that's why there must be mice and elephants in a data
network.
Then they went on to say basically mice and elephants happen everywhere. They looked
at forest fires in California and decided that if you look at the size of forest fires, there's a
small number of forest fires which cause a huge amount of devastation and large numbers
of small fires which don't do very much. And same with earthquakes. Same with
virtually everything in the natural world [inaudible] these power law distributions.
So whatever the precise cause of heavy tails, they're here and we're just going to live with
them. And I'd say more generally any network at all, any general-purpose network will
always be designed to carry mice and elephants, because users just want to carry -- want
to send elephants and that's -- all networks carry elephants.
And elephants are what network traffic engineers spend all their time looking at. This is
a picture of a head of cauliflower, which has a reference to self-similar characteristics of
network traffic, which is what this -- all this research from AT&T was. Important
network traffic properties are governed by the large flows, therefore if you look at what
network engineers traffic people do, they only ever look at the elephants.
Which is a big mistake. It's missing out a large part. Most traffic comes from elephants,
and so capacity planning is based on elephants. But what users really care about is the
mice, because that's what makes up the user experience, the interactive user experience
[inaudible] exchanging very many short flows, composing -- which go to compose a
complex task.
Here's a quick example. On your iPhone sending an SMS saying I'm trapped in an
avalanche and giving your coordinates, which is 50 bytes of text. Please wait. Busy
downloading iTunes update, 1.7 megabytes remaining.
Okay. So mice are really important to users, and somehow they've been a bit overlooked
by the network traffic community.
What does it mean for our purposes for how to improve things on networks? Well, here's
a really simple, brain-dead answer. To speed up transactions, because of the problem of
this early packet loss on the performance of Web page downloads and so on, why not just
send multiple copies? This is a very, very simple form of forward error correction. So
instead of sending one SYN you send five SYNs together.
If you do this, it would not cause very much extra traffic at all. Here's something which I
found really striking. I have two different schemes here for aggressive forward error
correction. This one's the fairly simple scheme. I'll imagine a really simple hack to TCP.
I'll make TCP send three copies of the first packet in each flow, two of the second, and
one copy of the third packet in every flow and one copy of every packet thereafter. And I
asked if you did this, if you enlarged each flow in this way, how much extra traffic would
it cause. Answer, in 1984 it would increase traffic by 34 percent. And in 2005 it would
increase traffic by 2.7 percent. So what's happening here is that the elephants are just
getting bigger and bigger and bigger. Back then I don't know what the elephants were,
FTP downloads of programs, of short, small programs, I guess. Here the FTPs in 2005, I
guess, it's downloading short movie clips. Now it's downloading high-definition movies.
>>: That depends on your assumption [inaudible] lost processes. If you send multiple
copies of the same packet and the losses are [inaudible] you're not going to do a whole lot
better.
>> Damon Wischik: Yeah. I'm coming to that in a moment. And there's a comment
here. There's no point sending packets too close because if you send them too close
they'll share the same fate.
>>: If you want [inaudible] the only thing that you need to do is keep [inaudible] so I
would argue -- and this is I think something that [inaudible] earlier is simply send smaller
packet. Rather than sending bigger packet, send a large number of smaller packets.
>> Damon Wischik: But that's my point. [inaudible] keeping the at clock going. That's
something suitable for when you have a large flow of stuff with many packets. The
whole thing about short flows is that there's such a tiny fraction of network traffic volume
that you might as well just send multiple copies at the same time.
>>: But your problem there is you just saturate a network gear which works on packets.
It doesn't work on the flow. So, in other words, when you ->> Damon Wischik: No, right, right. You won't saturate the network because here I'm
just -- how many more packets in the network am I causing? 2.7 percent more packets.
>>: [inaudible] applications, which have very many tiny packets. They will melt a router
in many cases just because of the processing needed for each packet. The routers and
switches work on packets, they don't work on the data. You can care less about data. So
the smaller the packet -- the smaller [inaudible] ->> Damon Wischik: Yeah, okay.
>>: [inaudible] -- so you increase the amount of work that the switches and routers do.
You saturate the back [inaudible].
>> Damon Wischik: Yeah. This will definitely [inaudible] on the very short packets.
Typically they ->>: Anytime you increase the number of packets, you increase the load on the network
applications, which [inaudible] buffers [inaudible] certain devices which load the buffers
up and so on to cause problems, congestion.
>> Damon Wischik: [inaudible] the packets are the same size, then it's traffic volume
which matters rather than number of [inaudible] ->>: If you use more packets, you increase the number of packets.
>> Damon Wischik: Okay. But what's the increase in number of packets? The increase
in number of packets is negligible if you do this.
>>: I think your point is that the increase in number of packets at a link in the middle of
the network in a backbone link is going to be negligible.
>> Damon Wischik: Yeah.
>>: But when you think of a -- an application, like Messenger, where you've got servers
that are being pounded by millions [inaudible] ->> Damon Wischik: Oh, yeah, okay. So that is definitely an exceptional case. Or
another example would be a DNS server which only has mice. So I said any
general-purpose network has mice and elephants. The thing is, a DNS server is not really
a general-purpose network; it's a very specific thing. So this will not be a sensible idea
for certain types of application. If we're talking about just general network flow at a
typical core Internet router, I still think this is accurate. If we're talking about very
specific servers, where the traffic is entirely mice then, this is a bad idea.
>>: Are you looking at what the router does before [inaudible] ->>: Every router, every router you have has to deal with every packet.
>>: [inaudible].
>> Damon Wischik: Okay. But I'm saying that increase in number of packets will be 2.7
percent.
>>: That's not right [inaudible]. [inaudible] first router in front of your Web server,
increase the number of packets would be a 100 percent if you send every packet twice.
>> Damon Wischik: I'm not proposing that you send every packet twice; I'm proposing
you send the very first packets in a flow multiple times. So if it's a Web server which
serves mice and elephants, then the increase in traffic load will be small. If you have a
Web server which serves only mice, then this is a bad idea.
>>: The other thing you described in there is a SYN flood.
>> Damon Wischik: Is what?
>>: Is SYN flood. You just described a SYN flood.
>> Damon Wischik: Yes.
>>: In other words, I send a whole bunch of SYNs to a machine from a source and I
expect the machine to send back [inaudible] you just opened all these sockets. That's
why we have syncopes, to slow it down and protect the server from getting flooded with
half-open sessions.
>> Damon Wischik: Why does it need more ->>: If I send you a SYN, you're gonna send me a SYN-ACK. If I sent you five of them,
you're going to send me five SYN-ACKs. You've opened up five sessions one after
another.
>> Damon Wischik: I don't know enough about TCP internals. Don't the duplicate
copies of the SYN go to the same half-open connection?
>>: Duplicate copies of the SYN? You would send five different [inaudible] five
different SYNs coming. I'm going to open up five different sessions, so I'm going to see
five duplicate packets, which is a bad thing.
>>: So you dropped four of them [inaudible].
>>: [inaudible].
>>: [inaudible].
>>: [inaudible] receive the SYN [inaudible] determine it's a duplicate, then you duplicate
packet -- to me it looks like a duplicate packet [inaudible].
>>: [inaudible].
>>: [inaudible] I may respond to all five. I may close one session, start the next one,
close this session, start the next one. It's all very specific to the device. [inaudible] the
SYN is the most [inaudible] ->>: I think he's implying that we shouldn't do that [inaudible].
>>: You said three copies. I'm going to have three SYNs hit me and I'm going to have to
work on all three.
>>: You process all three, then you drop two.
>>: But to drop the two, I still have to process all three.
>> Damon Wischik: Yeah. So it definitely -- this is really a serious hit on Web servers
where the quantity of serving mice is a big issue. I don't know enough about just sort of
general network architecture to know how much that's a bottleneck in things which are
happening.
So I'm going to go on to talk about this point, about the network characteristics of these.
Here are several different pictures of packet drops in the Internet. This is for measuring
end-to-end performance. Here's a measurement study from around 2000 of a link
between a U.S. university and Sweden, which decided average packet drops is around 3
percent.
They also looked at the correlation between packet drops, and basically if you send two
packets more than 50 or a hundred milliseconds apart, then they will be pretty much
independent. So that's a plausible time. I think it's silly going less than 50 milliseconds,
but a hundred milliseconds should be safe.
Here was another measurement study. This is looking at a wireless link where it
alternates between periods of virtually zero percent loss going up to 80 percent loss for
when they turned on the milling machinery in the room next door. But this figure of a
hundred milliseconds, it was roughly true there as well.
And then there's this theoretical work which says that you would expect to see bursts of
drops in a router and the bursts of drops ought to happen roughly separated by something
of the order of several roundtrip times. So these are several different pictures of
correlations and they all go to support this idea that in the network this 50 to a hundred
millisecond time scale is roughly the right idea.
>>: Where does that magic number come from?
>> Damon Wischik: I -- I only can give an answer for that based on the theory side. And
the theory side says that it's about the control, the interaction between TCP and the
queuing behavior, that TCP sending data, it causes bursts. It backs off and it backs off
too much and then it goes up and causes bursts again. So that's basically what I'd expect
TCP to do, to create correlations over this sort of time scale.
>>: [inaudible] all the roundtrip times of the ->> Damon Wischik: Yeah, that sort of thing. I mean, the precise multiple of roundtrip
time depends on the network.
>>: I would assume that you have a series of flows all in synch together causing the
problem, to enable [inaudible] ->> Damon Wischik: Yes. And that's the linking back to the work on buffer sizing. It
turns out that the buffer size is what causes synchronization. If you set your buffer
wrong, then you'll induce synchronization between the TCP flows, the buffer at the
bottleneck router. They're the buffer that TCPs are responding to.
>>: [inaudible] most of the time? I mean, most of ours are [inaudible] I mean, it makes
sense the 50 millisecond time, 50 to a hundred millisecond time makes sense because of
the housekeeping routines performed in a router to clear our congestion.
>> Damon Wischik: I'm not talking about what the queuing is; I'm talking about the
interaction of the control, the [inaudible] TCP sends stuff, the -- TCP is responding to
congestion. Congestion happens over the time scale of queuing phenomena there, and
then the feedback comes, and then TCP reacts. And so depending on how big the buffer
is in this bottleneck router, the buffer size will determine the dynamics of this roundtrip
time control loop, and that will induce the correlations and synchronizations, depending
on the scale of the buffer.
>> Albert Greenberg: Let me suggest we hold the questions down.
>> Damon Wischik: Latencies. Well, you can't do anything much about the speed of
light. I looked up what are acceptable latencies. Answer, 220 milliseconds for playing
Counter-Strike, 50 milliseconds for playing Wolfenstein. Five seconds to download The
Washington Post.
All right. Now on to theory. Problem statement. I want to know how well do network
transactions perform over unreliable networks and how should we design network
transactions to make these things more robust.
This is basically what people have done so far. Typically you assume asynchronous
network or you assume an asynchronous with reliable delivery or -- and you asked the
question what's the execution time of the algorithm, the number of messages, and you
look for limit theorems as n, the number of nodes in the system, n tends to infinity.
There's very large and well-established study of distribution algorithms based on this sort
of way of looking at things, which I don't think has anything useful to say for these
particular types of problems.
First thing, this assume an asynchronous network -- I'll cross that out. The Internet is just
unreliable asynchronous. That's what we have to live with. It's no use proving a theorem
which says that it is impossible to reliably deliver a Web page.
Next question. What's the execution time in the number of messages. Well, I don't like
this thing, the number of messages, because it will be an impact on the server. It won't be
an impact on the network.
The thing I have most trouble with is this one. They look for a limit as the number of
nodes n tends to infinity. The trouble with that is you that just can't look at interesting
networks if you say n tends to infinity. If you say I'm going to look at a network with n
nodes, then that n to infinity, you have to impose some very regular structure on the
network to get answers out. So you can't have answers which say, well, it depends on
this roundtrip time and this roundtrip time and the way they interact. So this n tends to
infinity is just a bad way, I think, to proceed.
I'm going to suggest a different way of doing these limits. I'm going to have a fixed n,
fixed number of nodes in -- fixed [inaudible] fixed roundtrip times between them. And I
shall look for asymptotic SYN packet drop probability p as p tends to zero, because at
least it's a starting point that should give me some answers.
This is where I'd like to end up with ideally, something like how does the performance of
NFS degrade as the network becomes crummy. That would be a wonderful point to get
to at the end. I'm definitely nowhere near that yet.
So, I'll give three examples of network transactions. The first one's a very simple
question. It's reliable delivery. I'm imagining a sequence of links, each link with its own
packet drop probability and roundtrip time. And let's suppose I want to send a message
from here to here and I want to make sure it's sent reliably, and I'll look at two different
ways of doing it.
The first thing is hop-by-hop reliable delivery. I'd send a packet. As soon as this
receives the packet, it will send an ACK. And as soon as this receives the packet it will
send an ACK and so on. And this note here will keep on sending until it gets an ACK
back. So hop-by-hop reliable delivery. Or you could do end-to-end reliable delivery.
Just treat these nodes as dumb things in the middle and wait for the message to come
back.
And so what's the performance metric? Well, what you could do, as I suggested before,
is you cut the retransmit timer to be very short. And if you make the retransmit time very
short, you can achieve reliable delivery very quickly in either case. So it's not a good
enough question to ask just how long does this take, because you can make it be
arbitrarily quick by being arbitrarily aggressive.
Instead I'll ask a different question. Suppose we've tuned the retransmit timeouts to
achieve reliable delivery within a certain time frame. How many retransmit timeouts
does it need to use. So, yes, this is saying that it's retransmit timeouts, it's computational
power at these nodes which matters, which we need to control.
And the answer basically is it's some pi, it's some packet drop probability on one of the
links is particularly high, then hop-by-hop is better. Otherwise end-to-end is better. This
won't be news to anyone. I mean, everyone knows you have hop-by-hop reliable
delivery, at least for the wireless link from you to your wireless base station, and then
there's end-to-end reliable delivery over the core of the Internet. So the answer here is
not at all surprising. It's just nice to be able to write down a simple model which gives
you some algebraic way of getting to this answer.
Here's another example. This is retrieving the Web page. There's the Hotmail Web page.
So here I'll ask what's the expected time until the Web browser retrieves the entire page.
It's a function of roundtrip time and packet drop probability. And actually there are three
different flavors, three different versions of http, which all give different answers. And
http won't point node. For every single one of these items, you open up a new TCP
connection. And the standard is to have no more than four simultaneous TCP
connections. In http 1.1 they decided that was a bit silly because it's stupid sending
SYN/ACK for every single item when you're all typically going to the same server. So
http 1.1 says, well, we'll pipeline them, I'll send the SYN/ACK once, but then thereafter
I'll send multiple -- I can send a request, get the answer back, send the next request, get
the answer back, send the next. On the single TCP flow. And the default is to use two
TCP flows. And then there's http 1.1 with pipelining, which is similar, but you're allowed
to do the SYN/ACK, request, request, request, get the answers back simultaneously.
These numbers, there's some interesting stuff behind the numbers here. There's no more
than four TCP flows. Many people think it's to be kind to the network. If end users
could open up very large number of connections, then it would flood the network. That's
actually not the reason for the number four. Based on archaeological work through very
early e-mail lists to do with Netscape, Mosaic, they chose the number four because they
imagine a dial-up user on a 56k modem who's got five simultaneous TCP connections
open. If you imagine a typical roundtrip time, each of those five TCP connections has a
window size of roughly a bit under one packet, which messes up the at clock. And so the
performance for the user is terrible when it gets that little bandwidth per flow. So they
put in this number four to save the user from themselves.
It was sensible that if you have users on 56k modems downloading large actions, it's
completely useless nowadays when we have fast connections when we're downloading
mice.
I couldn't find any explanation of why they did this number two. This pipelining thing,
Firefox claims it's the only Web browser which implements pipelining. When I last
checked, the Internet Explorer blog said they were not implementing pipelining because
the way proxies and so on are set up. If you try and implement it, it just won't work. So I
reckon that Firefox implements it but it just doesn't work and they don't realize.
>>: [inaudible] actually [inaudible] work on this a while ago and one of the problems
with pipelining obviously is you can have [inaudible] the database is stuck [inaudible].
>> Damon Wischik: So I asked -- so this is -- the calculations are for the Google Web
page. I asked how long did it take to retrieve the Web page. Well, for http 1.0, 50
roundtrip times plus 30 times packet drop probability p times retransmit timeout plus O
with p squared term. So this is what I mean by looking at asymptotics in terms of p. And
you get this formula just by reasonably simple counting of what the possible outcomes
are.
Http 1.1 makes virtually no difference to this. In fact, if you have a [inaudible] network,
it makes things worse. And http 1.1 with pipelining, assuming the pipelining is all done
right and there aren't large delays at the server, then it's got much better performance.
The trouble here is that the Web pages are typically structured to be taller than they are
wide and the pipelining just doesn't help you very much and it's the restriction to two
TCP flows which was the killer.
Here I looked at the different e-mail service providers. I said that was the old version of
Google that I looked at. In 2008, they updated their Web page and it's faster now. This
is what Hotmail Live is. It's still substantially longer than the one roundtrip time we'd
like in an ideal network.
Okay. So those are two very trivial examples. If all I was going to talk about was the
performance of Web page download, there'd be no point in me talking. You can do
theory for that easily. I want to look at more interesting algorithms, distributed
algorithms [inaudible]. And so to talk about distributed algorithms, I need to be more
clear about what the objectives are. This is what I call the hierarchy of needs for
distributed algorithm. And I'll work through the bottom three in the next few slides,
composability [inaudible] safety and liveness.
All right. Composability. Let's just take this example of reliable delivery. Reliable
delivery happens at the MAC layer, like you to your wi-fi base station. There'll be
reliable delivery of cells there. Reliable delivery happens in TCP end-to-end. It uses
timeouts and gets reliable delivery of packets. And then there's reliable delivery
implemented in JavaScript.
>>: I would say that MAC layer it is the opposite way around, often is unreliable. In
most cases it's an unreliable blueprint. If you're running Ethernet, it's absolutely
unreliable.
>> Damon Wischik: Yes. [inaudible] but for wireless they need to have reliable delivery
at the MAC layer, because otherwise it would just be too crummy.
>>: [inaudible] that it's -- absolutely will be unreliable after that [inaudible].
>> Damon Wischik: Yeah, yeah. So there is some reliability delivered, implemented
here [inaudible] that works.
So what's puzzling here is that there's reliable delivery done at all different points in the
network stack. How do these different mechanisms interact if you wanted. If you really
want to achieve a certain level of performance, how should you tune these things. Should
they be communicating in any way? I don't know. It would be great to have a type of
theory which let's you talk about questions like where in the network stack should this
functionality be done.
Safety. An algorithm is safe if at all instance for every possible execution trace such an
appropriate in variance are satisfied. I'll give an example. Here's an invariant. If Juliet is
pretending to be dead, then Romeo knows the plan. So this is an example of a bad
network transaction. Friar Lawrence sends a message to Romeo saying Juliet will
pretend to be dead, and he sends a message to Juliet saying pretend to be dead. And this
message was dropped. This message got through. And it ended in tragedy because it
doesn't satisfy this invariant. If, however, you had structured the transaction differently,
it would have been perfect. It would have been a comedy rather than a tragedy.
Okay. So basically we want algorithms to satisfy certain safety properties and different
types of task need different safety properties. I talked about probabilistic models with
packet drop probability p and so on. From what I've seen, people want safety property to
be satisfied for every possible execution trace. So this is a bit odd to a probabilist who's
used to thinking of almost surely, basically computer scientists don't trust probabilicity
enough to write good probability models, and so you want to make absolutely certain that
nothing can go wrong. Their only interest in algorithms which -- which won't mess up.
The liveness. A lot of the work on distributed algorithms has looked at algorithms which
looked something like this. Let's say I'm trying to write a program which has a leader
election component. For example, I'm trying to elect a main server in an ad hoc wireless
network. You might write let X equal get leader, then you'll send a message to the
leader. And the get leader function might look like this. While true, it continues to
exchange messages and as time runs longer and longer, it will be more likely to have a
correct answer. But many of these algorithms which people have analyzed, they never
actually terminate. And that's not terribly useful.
I'll be interested in algorithms in which each node eventually finishes its execution almost
surely.
So hierarchy of needs. We want our analysis to be able to tell us something about
layering and composing. We want to look at algorithms which satisfy suitable safety
properties. We want algorithms which should terminate almost surely. I've written this
"almost surely" because there's always a possibility that the algorithm will never
terminate. For example, if I'm retrieving a Web page, it's possible that every single
message between me and the Web server would be dropped. But that is so unlikely that
we won't worry about it. So probabilistically I'll say almost surely the algorithm should
terminate.
Correctness. With high probability when it terminates it should give us the correct
answer. And latency, I'll be interested in the expected time to terminate. So the
hierarchy of needs, four different levels of probabilistic guarantees.
And here's a complicated and interesting example of an algorithm, which I'll work
through in this way. This is the leader election problem. Leader election is an ancient
problem. But good place to start. I looked through a bunch of different leader election
algorithms, so I couldn't find any which were simply enough for me to analyze in this -I'm trying to understand the performance characteristics in an unreliable network. So I
had to come up with my own very simple leader election algorithm.
This is what it does. I'm imagining you have a bunch of computers on the network, a
shared network with the hub. A collection of princes and courtiers and the objective of
the algorithm is to elect one of them to be a leader. And a suitable safety property it
seemed to me is that if X thinks Y is the leader, then Y thinks that Y is the leader. I'm
thinking, for example, of trying to elect, say, a name server in an ad hoc wireless
network. I read that Windows XP does this when you set up a wireless ad hoc network, it
elects one of them to by the name server. I found that whenever I set them up it never did
that reliably, so I wanted to look at this. So this means that, for example, if I think that
you're a leader and I send you a message assuming you're a leader, then at least you'll not
not choke on the message. That's a plausible safety requirement.
It's no good guaranteeing -- it's no good requesting that we only ever elect one side of the
leader. For example, this side of the room might elect a leader and that side might elect a
leader. And if all messages between the two sides of the room are drooped, then there's
no way to insist that we only ever have one leader. So that's no good. And the
termination property, once we've accepted a leader we should not change our minds.
And this algorithm -- I guess I won't go through the details, because this is -- it's an
algorithm based on two rounds, and then it has a bunch of messages here, but that's not -I won't dwell on it. What's good is that I was actually able to get somewhere with
analyzing it. Lemma, the expected number of leaders elected is one plus two p plus O
with p squared. In other words, if p is zero, you'll have one leader elected, which is very
a useful property. If p is small, there's a chance that we'll have two leaders elected. And
also you can work out the time it takes for this algorithm to finish, explicitly in terms of
the message delays in this network. The completion time, it depends on who the closest
nodes are to the hub. So it's nice to have bounds which explicitly incorporate what the
structure of the network is. And it's nice that it depends on who's closest. It doesn't slow
down if there's someone who's three miles away.
All right. So this really is just a proof of concept. Just a simple, classic problem. Fairly
simple algorithm. And that's the starting point for this project of analyzing distributed
algorithms in unreliable networks.
Okay. So this is what I've talked about. A definition. The network transaction is a
coordinated exchange of short messages between computers on an unreliable network.
I'm interested in algorithms which satisfy safety, liveness, correctness, and have good
latency. I want to know how well do these algorithms work when the network is
unreliable. And I want answers which tell me about just how the performance relates to
the structure of the network. And the real challenge is trying to do it in a way which let's
me say, for example, I'm using hop-by-hop delivery here as a leader election algorithm,
which is then part of something bigger. That's a very big challenge, I think.
Here are some very simple suggestions. We might tweak TCP to send mice more
aggressively, although not too aggressively. Maybe we should allow Web browsers to
send several mice simultaneously. This limit of two isn't really suitable.
Here's something which should be interesting from the theory point of view. Divide
some sort of standard template library of distributed algorithms where in the standard
template library you say what the running time and memory requirements are as a
function of problem size. I'd like to have a library of algorithms where you say what the
running time and correctness is is a function of network reliability.
Well, here's a way-out idea. This idea of layering, the idea that reliable delivery is
implemented at many parts of the network stack, you could imagine when the top-level
function is called -- like when the user clicks on something, it creates a timeout pool, and
every single timeout lower down in the network stack, in the API stack, it subtracts from
this timeout pool. And when the timeout pool runs out, it runs control to the user. That
way the user -- the programmer would have some control over the user experience.
There's no point trying to do this unless you have some sense of how long different
network tasks should take to complete, and so that's why it's nice to have some way of
analyzing performance network tasks.
Okay. So that's just restating the summary. Thank you.
[applause]
>>: Are there any suggestions -- so where I look at the last [inaudible] last slide, right,
the first thing that occurs to me is it will be great to have an analysis of how the first
suggestions affect the network itself, both in the core and on the edge, right? So these are
great suggestions, but we really just don't know [inaudible] how does it affect the
network?
And the second thing is I want to know if you thought about that and if you have any
problems with that. See, another thing is, what does the Web server do? I mean, some of
this stuff is not controlled by people in this room. It's tough. To begin TCP is a really,
really hard thing to do [inaudible]. Web browser is -- Web browser design is fine. We
have IE here, but that's a tough thing to do as well. On the stuff you can control
[inaudible] Web server, is there anything you can do there?
>> Damon Wischik: The ->>: [inaudible] so one of the things, for example -- this is not something [inaudible] it's a
very easy [inaudible] as the initial condition window of two packets [inaudible] it would
take at least one roundtrip time just like [inaudible].
>> Damon Wischik: Yeah. That's correct if you have enough packets to fill up that
initial congestion window.
>>: [inaudible] are more than about 4,000 bytes.
>> Damon Wischik: And the pages is a whole lot. But, for example, on these things,
many of the items are just half a packet big. So -- yeah.
>>: [inaudible] it won't do anything for pages that are [inaudible] ->> Damon Wischik: Yeah. So that's definitely a great idea and I think that adding a little
bit more aggressivity, like sending the thing -- let's say send a packet and then a hundred
milliseconds later send the packet again, I ->>: Well, the customer, I mean, with the receiving system can't handle it, if he has an
[inaudible] back or whatever, what's the purpose of sending it if you're going to drop it at
the receiving end?
>> Damon Wischik: Why can't they handle it? It will just be a duplicate packet if he
gets them both.
>>: How can create duplicates?
>> Damon Wischik: Yeah. So there's definitely a question about how much overload
that will cause.
>>: Because you're not causing IOs to receiving in and to sending into.
>>: Yeah, but those things are cheap, cost end power is cheap, right?
>>: Not if the receiving system is on demand. I mean, a lot of our customers do not have
the latest and greatest PC. Also, you hit firewalls, proxies, other things that have to look
at these extra frames.
>>: Well, agree with you. I think what he's saying is in 2008 some of those things are
less a problem [inaudible].
>>: For the host.
>>: Yeah.
>>: Not -- not on top of everything else. And it still becomes an issue of you now
sending [inaudible].
>>: [inaudible] I mean, loads will get faster [inaudible] will get faster as they get more
numerous.
>> Damon Wischik: And today there's probably -- you definitely would want to think
about redesigning the hardware, maybe going that far to design hardware which is more
used to receiving duplicate packets. That one's harder to do. There's some tweaking TCP
to send mice more aggressively. I think that's very easy to modify, because this
modification doesn't require any -- you can do it in one place. Like you could do it just
too the end system and it doesn't require any cooperation from the network.
>>: Wait. This is not like a tweak on a Vista, right? You have to literally [inaudible].
>>: [inaudible].
>>: Absolutely.
>> Damon Wischik: Yeah. Yeah. So that would happen fairly quickly with Linux, I
suppose.
>>: [inaudible].
>>: Yes.
>>: Have to modify firewalls ->> Damon Wischik: These things should all cope with duplicate packets because ->>: [inaudible] exactly the same IP ID? Are you [inaudible] ->> Damon Wischik: It should be precisely the same packet.
>>: [inaudible] sending duplicate frames, you have errors everywhere. You're going to
have error alarms everywhere.
>>: You will have -- [inaudible] this packet has to be informed by the application that,
hey, this is mice flow, okay, and that you -- to some extent you're going to introduce that
because maybe the connection already close, so Windows actually has something already
where the close are very short, less than 8k, it does something different. But then now
you're [inaudible] specifically, hey, you know this was only two packets long or
something along those lines. Now there's something special.
>> Damon Wischik: Well, that's why I suggested send three copies of the first packet,
two of the second packet.
>>: [inaudible] how is this packet going to know that this is a [inaudible]?
>>: [inaudible].
>> Damon Wischik: It doesn't. I said for every single flow, send three copies of the first,
two of the second. That would be a simple way to be more aggressive.
Now, should the rest of the network cope with duplicate packets ->>: You're now going to introduce as a standard function an error condition that we look
for. Because a duplicate packet does exactly the same as any other packet: indicates a
loop exists in the network. Therefore, I need to go hunt it down and kill it quick.
>> Damon Wischik: Right. [inaudible] I thought -- that's not part of the ->>: [inaudible] packet in the network has been generated. And then a receiving -- a
system looking at that, passing it through, sees exactly the same packet again, okay, by
the way the [inaudible] are set up, which have a single path in the network. If I see the
same packet twice, then I must have a loop in the network. If I have a loop in the
network, then I need to go kill it quick, find out where it is. So duplicate packets are
always an error in the network at every layer.
>> Damon Wischik: That is not my understanding of the original IP stuff.
>>: If I look at -- if I see a packet once and I see it again, exactly the same, if you're
sending me a dup on retransmission, you have differences in the packet that needs
different -- does other things different, the time stamps are different, the [inaudible]
different, whatever. If I see exactly the same packet twice in the network, the only reason
I see that packet is because a loop has existed.
>>: [inaudible].
>>: When you think about it, the only thing you can have is a loop right now.
>>: And then the host, do they react to [inaudible]?
>>: So also if the computer [inaudible] that some of the [inaudible] so it might
[inaudible] some of those.
>>: He can -- it helps if he can make the packet look a little different.
>>: So you can make it have a different IP ID, for example, and that might help. Then
you have to make sure that this end system does not send out a new pack, because if it
sends out a new pack by mistake, [inaudible] then you would have [inaudible] ->>: If you make the packet different, then the receiving system may set up a new session.
Now you have two sessions open because now it's not a duplicate packet.
>>: We're going to have to change the host. I'm not so sure about the switch. But the
switch is going to work [inaudible].
>>: It's something that you really want to be careful of because you're going to kick
[inaudible] all over the place.
>> Damon Wischik: It's like the ECN bit, which if you set ECN capable in packets, then
it causes Comcast cable modems to simply shut down completely. Some of these things
switched should never have happened, but unfortunately it does.
>>: [inaudible] reject it.
>> Damon Wischik: They don't just reject it, they crash.
>>: Yeah.
>>: No, no, you're not supposed to crash on packets you don't understand.
>>: No, I understood [inaudible] ->>: That's a bug.
>>: Yeah, it's a bug. We ignore it. We ignore the network now because everybody
wants to be the highest priority.
>>: But let's go back to -- let's not worry about the network for a second. Let's think
about the end systems [inaudible] to be more aggressive, at that point be ->>: I mean, Jay has a good solution. If the biggest problem is that our close time was
three seconds, why don't we change that? That requires the least amount of change and
we don't [inaudible] extra packets and we know that most [inaudible] times in the world
now readily exceed [inaudible] milliseconds [inaudible] why bother with this [inaudible]?
>>: And that's a change you can make without releasing the stack, right?
>>: No, that's a change you will have make by using the stack [inaudible] I think
[inaudible].
>>: [inaudible] not exposed.
>> Damon Wischik: I have to look at the [inaudible] options in Firefox. In Firefox you
can tell it how many simultaneous connections to open various configurations. The
default is two simultaneous connections, and it allows so many things to be pipelined on
each of them. And I set the defaults -- I changed them from being 204 to around 5,000
and it had no measurable benefit. I guess there were either [inaudible] implementations
or head of line blocking or something similar.
I think also that more intelligent Web browsers, more intelligent ways to cope with mice
would be well worth [inaudible]. I read about a group which is basically a group of
AJAX developers with a wish list for what they want next generation of Web browsers to
do. This was the first item on the list, I think, they allow us more than two simultaneous
connections.
>>: I mean, it's kind of depressing that http 1.0 is a little better [inaudible].
>> Damon Wischik: Maybe it was a design goal that they didn't want 1.1 to be too much
more aggressive. I don't know.
>>: Your third point there, well understood latency, what do you well understood
latency?
>> Damon Wischik: I mean things like -- like in the standard template library, you say
running time is over [inaudible] squared. I'd like to say something here like running time
is such and such a function of latency and [inaudible] drop probability.
>> Albert Greenberg: So, again, Damon will be around for a few more hours today -- or
are you -- what's your plans?
>> Damon Wischik: A few more hours today.
>> Albert Greenberg: Okay. And if there's folks that want to talk to him further, he's
around next week starting Tuesday. Just let me know, Albert at research -albert@microsoft.com. Sorry.
>> Damon Wischik: Thank you.