17330
>>: Great. It's my pleasure to introduce Eric Keller and Minlan Yu, Ph.D. students from
Princeton, each will give a half-hour talk on their research work.
We'll start with Eric talking about accountability issues in hosted virtual networks.
>> Eric Keller: So the title of the talk is Accountability in Hosted Virtual Networks. That's just
what Jen just said. I'm Eric Keller. And the motivation of this work is this trend towards hosted
virtualized infrastructures. This is realized today for server infrastructure and most notably
Amazon EC2 is well known. And these enable companies to easily deploy new services without
the need for building out infrastructure.
Now, I believe this trend will continue into the networking space in the form of hosted virtual
networks. And this trend has already started, routers are being virtualized. The router vendors
are opening up the platform for more programmability.
But taking that next step of making it a hosted platform, I feel that would really open the network
for innovation.
So in this model there's two parties. Infrastructure provider owns and maintains the routers. And
the service provider leases slices of routers from one or more infrastructure provider and runs
their service on it.
So in this talk I'm going to take a look at new security threats that arise in this model and take a
first step at defining the problem, taking a look at the applicability of available technology for
solving this problem, and looking at new architectures that address the limitations of existing
technology.
So to understand the security threats, let's take a look at what the two parties want. So the
service provider wants its control software running exactly as it was written. It wants the data
plane to act exactly as it was instructed, both in terms of forwarding and filtering, as it was
configured, and with the quality of service that was promised.
It also cares about the confidentiality of its data. It cares about availability, but I'm not addressing
that with this so that it's separate.
The infrastructure provider on the other hand doesn't want to be unjustly blamed for problems
that it didn't cause. It would be easy enough for the service provider that has a bug in its code to
just pass off the problem to the infrastructure provider and say you track it down.
So the infrastructure provider doesn't want to invest that time and effort to have to be able to do it.
So let's take a look at how these are possibly compromised. So in the old model these two
parties are one in the same, the service provider and the infrastructure provider are the same.
The service provider owns its own routers. So there's two generic architectures for a router,
hardware-based router where the forwarding is done on line cards or in a software-based router
where the forwarding is done inside of the, in software inside the kernel of the operating system.
In either case, the routing processes run in software on top of an OS.
And in this model the entire platform is trusted. Two parties are one in the same. So there's no
real concern. So in the new model, the first threat is that it's hosted. To get this platform to be
able to host other virtual routers, you insert this virtualization layer. And you still have the routing
processes and operating system running, and that's the service providers' code. But this
virtualization layer is this infrastructure provider. One possibility is for the forwarding functionality
to be inside of the operating system of a guest virtual machine, but for any kind of performance,
I'm assuming that this is going to be inside of the virtualization layer.
So the threats here are the infrastructure provider can tamper with the control software. They can
tamper with the data plane configuration in the hardware router case, as the configuration goes
through the virtualization layer or the infrastructure provider can tamper with the data plane
implementation in a software-based model.
The second threat is that this platform is shared.
Not only do you have this virtualization layer but you're now running a separate service providers
get to run their code on this platform as well. So in this case the other service provider could be a
competing service provider that can actively attack the virtualization layer to effect your
performance or operation.
So the security threats lead to the need for accountability. So that's where the title comes from.
So looking at the definition of accountable, it's subject to the obligation to report, explain or justify
something, responsible, answerable.
So in hosted virtual infrastructures, this is contained within the service level agreement. So now
I'm going to take a look at the two different approaches. One is to detect violations that have
occurred and another is to prevent violations from occurring in the first place.
And for each of these I'm going to take a look at something that's possible today and then look at
the limitations of it and then propose an extension. So this is very early work. So keep that in
mind.
So first taking a look at detection using network measurement. So by its nature detection detects
after the fact. So it can't really address any kind of confidentiality issues. But the problem is very
similar to something that's going on today, that ISPs are already measuring and monitoring their
own networks or the networks of connectivity that they're receiving.
And so you can use similar techniques. You can use probing to determine loss rates. Latency,
the path that a packet is taking. But because you don't necessarily trust the infrastructure
provider, you can't really trust that they're telling you the truth.
If you're running measurements from within their network. But you can take advantage of the fact
or the assumption that service providers will be running on more than one infrastructure provider.
So you can basically surround the infrastructure provider on to test and measure it from the
outside.
And to know how the data plane was supposed to be acting you can log the control messages
that are going into and out of this sub network and then model that network and replay the logs.
So this approach has some limitations. So we think that one possible extension is to extend the
interface card to do a lot of this functionality. So interface of each of the routers would have some
kind of functionality.
So to go through each limitation, the first logging, the control messages at the edge to determine
how the network was supposed to behave, this causes -- it's expensive to simulate. That you
have to model the network and replay these messages.
Instead, if you can log the control messages at each interface then all you need to be able to do
is model a single router. Similarly, probing at the edge makes it difficult to pinpoint any particular
faulty router. If there was only one router that was compromised pinpointing it is difficult. There's
a trade-off how much you're measuring versus the accuracy you can get.
Instead, if you can sample at the interface instead, your accuracy goes directly to the router in
question.
And probing at the edge also makes it so that you don't know what the exact path that is taken.
You only know the ingress and egress of that sub network. But you don't know the complete path
that was taken.
So, again, doing this at the interface, there's something called the IP trace-back, which you
basically keep a bloom filter and every packet that comes through you packet it into that bloom
filter and you can query whether or not any particular packet was seen and if you have that at
each ingress and egress you can know the path a particular packet went through the entire
network.
And finally one of the kind of main -- I don't know if it's a main concern -- but a big concern is that
this measurement is done by one party, the service provider.
It can't really address that problem that the infrastructure provider doesn't want to be blamed
unjustly. That these measurements the infrastructure provider can't really know how accurate
they are or anything like that.
So it can't be used to prove violation. But if instead we're using this network card which is
tamper-proof and it's created by this third party, each of the parties, the infrastructure provider
and the service provider are placing trust in this network card to do this logging, sign the results
and it's indisputable.
So the detection methods are only detecting after the fact. So is it possible to prevent violations
from occurring in the first place? So here we're going to look at advances in processes
architecture to see where they could fit in.
So the first thing is the trusted platform module. So stepping back, recalling what the service
provider wants, the control software running unmodified, the data plane acting as instructed and
with the correct quality of service and confidentiality of its data.
So the TPM or the trusted platform module, is a chip that's available today. It's on the
motherboard and I'm told it will be unchipped in the not too distant future. It's used for encrypting
storage and testing to the integrity of the system.
But it does have limitations. It doesn't protect against dynamic attacks. So what this means in
terms of what the service provider wants you can't ensure that this software is running
unmodified.
Second, it relies on a chain of trust that each layer is verified by a layer below it. So in this case
the virtual machines would be verified by the virtualization layer. So this means that you have to
place your trust in the virtualization layer.
And you can't know if the data plane is acting as instructed or with the correct quality of service
because the data plane is in the virtualization layer, and the configuration goes through the
virtualization layer, that if you're placing your trust in that, but you can't really trust it.
So neither of them is addressed. And, finally, the confidentiality of data is not addressed if you
can't do any of those.
But you can kind of make it work through physical separation. So the way it would work here is
so on the left I have the generic architecture that I started with. Instead, you can run your routing
processes on their own box or own processor protected by a TPM. Then you control the entire
platform.
And each one of them is separated. And the data plane would then in this case in the
hardware-based router it's easy. It's a line card. And software-based router, you can, I'm
assuming it's possible to run some very minimalistic operating system current with the forwarding
capability and some very minimal controller. But in no case do the routing processes of either
service provider have access other than through a very small API.
And this is not completely unrealistic, as routers today already have multiple processors on them.
They have multiple cards in them that they're these big chassises with a lot of things. So it's not
inconceivable that this could occur. But still the line on the physical separation and not really
taking advantage of virtualization, which is it's something that makes virtualization of routers
possible.
So instead I'm going to take a look at extending the processor architecture. So there's been a
decade of research that's been gone to looking at ways to make software tamper resistant. And
these are done through minimal security extensions to general purpose process architectures that
basically encrypt and decrypt data as it goes to and from memory.
The first problem is that none of them were designed for hosted and shared environment. The
second problem is that none of them really actually made it into any kind of production, that
they're all just research projects, even though they go back 10 years. And I believe that's
because none of them made a good business case. So that's why there's no success.
But I think the market size of hosted virtualized infrastructures provides this incentive. So to
understand at least at a high level how it would work, here's the base processor with the CPU
and the cache and main memory.
The first step is that I'm going to assume some trust in a vendor. Here a router vendor would
then install a private device key in their facility. This is a write-only register. So the software can't
read it. So nobody else will be able to know what it is other than the router vendor. And it's a
private key of a public key pair.
The service provider would then use that to install its own secret key. So it would take the -when it's going to be loaded onto a router, the infrastructure provider would say this is the router
you're going to run on, here's the public key of that router. That would be verified with the vendor
that's actually a proper key.
The service provider would encrypt its secret key with the device key, with the public key, send
that off to the infrastructure provider and then in instruction, that's an extension, it would be called
install key. That would take that value and install it into one of these slots.
And so here now this service provider has a secret key installed that nobody else knows about.
Finally, to protect the software and the data, as I was saying all data to and from memory can be
encrypted or decrypted or could just be hashed and verified as it goes to and from and that would
be just for integrity and have slightly better performance.
So what would happen is the service provider would take basically in one case its entire
executable and every line of memory would tag it with the hash of that memory line. And it would
send this executable off to the infrastructure provider. So this would make it that in no case can
any extra software be running.
So as it gets loaded into memory it gets verified in that engine, and it gets pulled into cache. It
can get modified and so forth and when it gets evicted it would go back through and recalculate
the hash key or the tag at the end of the memory line.
So because of this, there's no way that any other software is running, that this service provider
didn't verify or didn't allow.
So which is the right approach. Kind of benefits for each of them. Tried to create a little table in
terms of the trust, the runtime complexity, whether or not it enables or supports confidentiality.
And just looking at the main downside, the measurement-based approach, the main benefit of it is
that it's what -- it can be done today. It's very familiar to techniques that are done today. But
there's this trade-off between accuracy and computational and storage requirements.
The extended NIC, you would actually need to create this new NIC, which there may be
incentives to do so but it's unclear whether or not that's needed. So we need to look into that.
The TPM-based approach requires physical separation. So I think that the virtual mode, the
extended processor, which does need an extension to a general purpose processor, but it
provides all the protection that we want with minimal extra complexity. And there's the business
incentive for it to actually occur -- happen.
So in conclusion, we took a first step towards realizing hosted virtual networks, and this new
business model leads to new security issues. Namely, that the platform is hosted and that it is
shared.
You could use monitoring techniques to detect violations. I think it's better to rearchitect the
routers to prevent the violations from occurring in the first place.
So the future work would be to actually look at each of these further and go about figuring out all
the details of the extended processor more than at a high level and explore the implications of
trusting the vendor. That was one of the assumptions that kind of ran throughout, that we're
trusting this third-party, the router vendor. So that needs to be explored.
So thank you.
[Applause].
>>: I had a question about this physical separation that you said the TPM required. And by my
understanding you're saying you need that because you can't trust something in the software
stack. You had a slide up there that said you have to have a chain of trust and at each -- I'm
assuming what you're saying is that at every point there might be some software problem, some
bugs that can cause, break that chain of trust.
>> Eric Keller: Right.
>>: And you go on to argue that having physical separation will address that. But can't there
also be bugs in that kind of a -- factor it like that? Like similar kinds of ->> Eric Keller: I mean, this would -- I guess what's under the operating system in this case is the
BIOS, so, yes, you would have to trust that.
>>: Don't you still have the same software, just different places now?
>> Eric Keller: But this would have its own TPM that all it's doing is verifying.
So the physical separation, this would be on its own processor. You're booting that one
separately. It's almost like its own PC over here.
>>: I get that. But isn't it running the same software which can have the same bugs?
>> Eric Keller: But it's your software, as a service provider it's your software. If it's your bugs that
are causing problems, that's not what I'm addressing.
>>: Okay. But in the -- so in the other world I want a better understanding of where the software
is coming from. So you're saying in the virtualization layer, that software could have bugs that
came from the infrastructure provider, whereas in this case there is no software that comes from
the infrastructure provider.
>> Eric Keller: Exactly. So this is going towards the model of where you own your own router.
That you control all the software running on it. So there's no potential for this layer below it to
tamper with your software.
>>: But so there's still software running on these things that came from the hardware, the router
vendor. Why can't the virtualization layer come from the routing vendor as well, and once you
check all the hashes and so forth, you know it came from the routing vendor.
>> Eric Keller: That's possible. Because I'm not exactly sure how that would work, because
you're going to have a lot of different vendors. How many different images of that virtualization
layer is there going to be. So then do you have to -- I don't know, it's possible. So I definitely
would have to look at ->>: I guess maybe another way you could say this ->> Eric Keller: Again, it wouldn't protect against any kind of dynamic attack, though.
>>: Okay. The software is still vulnerable to dynamic attacks because ->> Eric Keller: But it's your software as opposed to the infrastructure provider itself. So a bad
employee goes on to the box and because it has access to the -- it would run some software
inside the virtualization layer. Even though it was verified at boot time.
>>: It would have to have been a bug in the software that allowed them to install extra software in
there.
>> Eric Keller: Or there could be -- yeah, if the router vendor says this is so hard and that
infrastructure provider even though you're asking for it there's going to be no way for you to run
any of your own software.
I don't know. I don't know if a router vendor would just make it that closed. But it's possible that
they could, I guess.
>>: I had a second question, if there's no other questions. So for -- I can't understand what my
question here was.
>> Eric Keller: I don't understand it either.
>>: Makes it hard for ->>: Okay. I'll skip that one. So for this, you said -- can you go to the slide with all the big table.
So where do you see these extensions, the processor modification showing up? Is it every chip
that can be, that handles data like all of the -- that can see like configuration data or something,
like all the porting point stuff or is it just the processors that are doing the sort of reconfigureable
control stuff ->> Eric Keller: So I would assume that -- right now, if you're talking in a hardware-based router,
those -- the line of cards I'm already assuming that are trusted. So there's some talk in just the
route processors that handle the control plane running on it. If it's a software-based router the
forwarding plane is running on software, and so in many cases it's running on the same
processor. There's only a single processor that's running the forwarding and each of the control
processes.
So I would assume that's one in the same.
>>: Is this just for confidentiality, this extension?
>> Eric Keller: No, it makes it so that -- if you can ensure that your software, control software is
running as you wrote it and a software-based router, if you can ensure that the data plane has
been unmodified and you can ensure that your configuration went from your control software to
the data plane in good tact, then all of those things mean that the router is operating as it was
supposed to, that there was no potential for tampering anywhere along the way.
So it covers the entire range of problems.
>>: I guess the reason -- so here I guess some of the unrelated work that you mentioned -- this
looks very easily like you just took multiple contexts, is what your plot diagram looked like. But
some of the other ones, like ZOM [phonetic] that deals with -- it helps address the problem of
multi-plexing across the multi process virtualization. So I think those extensions might be useful,
too.
>> Eric Keller: Yeah, I'd need to go back and reread. I don't remember about any mention of
virtualization.
>>: It doesn't have virtualization. But it gives you this -- gives you better hardware protection for
isolating different kinds of software. So that could be tweaked a little bit -- rather than doing that
work, the application's doing the work for the virtualization context.
>> Eric Keller: I'll definitely look at it.
>>: With current hardware accelerated virtualization, it's purely for making it easier to write a
virtualization layer. There is no support in those in things from what Intel and AMD's virtualization
technology, there's no support there for -- it's like protecting the virtual domains from the
hyperadvisor, which is this is analogous to the motivation which was to protect the applications
from potentially malicious operating system.
>> Eric Keller: There was some limitation with it but I can't think of it off the top of my head. I'll
go back and reread it. And if I can remember, then ->>: Thanks.
[applause]
>> Minlan Yu: So I will present BUFFALO, a bloom filter forwarding architecture for large
organizations. I mean, language from Princeton. This is joint work with LX Fab and Jane
Rexford.
So there's new trend to build a large layer two network that addresses because it makes it simple
for configuration and management and it is used for enterprise and data center networks.
For example, in this figure shows a large layer two network where there are lots of switches and
there are hosts connected to some of the switches. We generalize this network as flat network
which has shortest pass routing that addresses are flat. Flat addresses can be Mac addresses
and shortest pass routing can be link state or distance back to protocols, even spanning trip
protocols can be viewed as shortest best routing on a street topology. So to build such a large
layer to that work there is a scalability challenges.
For the control plane we need a scaleable protocols to disseminate topology and host information
and compute routes. These problems have been addressed by recent practical solutions such as
trio in Seattle. However, the data plane scalability remains a problem. This is due to two
reasons. First, with the increasing number of hosts and switches in the network, the forwarding
table keeps growing.
And at the same time the increasing link speed requires that we need to perform packet
forwarding or we need to scale the packet forwarding and increase the performance at the same
time.
So today's data plane typically use two techniques. The first is TCAM but it's expensive and
power-hungry. So a cheaper solution is to implement hash table in SRAM. However, with the
growth of forwarding tables, if the hash table no longer fits in the memory, then the data plane will
crash or perform poorly.
And it's very difficult and expensive to upgrade the memory in all the switches in the network. So
we propose BUFFALO or bloom filter forwarding architecture. The basic idea is to use bloom
filters in fast memory SRAM to reduce the memory usage.
Bloom filter is a compact data structure to store a set of elements. For example, to store element
X we calculate S hash functions and mark the corresponding positions as 1.
To check whether X belongs to the bloom filters, we check the S position to see if they are all well
or not. Bloom filters reduce the memory usage as expanse of false positives. So BUFFALO use
bloom filters to build the forwarding table.
We use one bloom filters for each next hop to store all the addresses that are forwarded to that
next hop. For example, if a switch has T next hops then we use T bloom filters each representing
one next hop. When a packet comes, we will query these bloom filters and check which bloom
filters contains the destination of the packet.
And if the packet hits, for example, the second bloom filters, then we know that we can forward
the packet to the second next hop.
To make this simple idea practical, there are several challenges. The first is how to optimize the
memory usage so that the false positive rate is minimized.
The second is how to handle false positives quickly yet without any memory and payload
overhead. Finally, bloom filters is typically fit for the state except so how to handle routing
dynamics makes it easy and fast to adapt these bloom filters. So we come to discuss the first
problem, how to optimize memory usage.
We formulate an optimization problem with the goal that minimize the overall false positive rates.
This is defined as a probability that in a switch one of the bloom filters has a false positive. The
input is a fast memory size of the switch and for the fixed forwarding tables the number of
destinations for each next hop. And we will also want to bound the maximum number of hash
functions to keep up the forwarding rate, the forwarding performance.
The output is the size for each bloom filters knows that we use different sizes for different bloom
filters, because for those next hops that has larger number of destinations we need larger bloom
filters.
So these optimization problems has two constraints. The first is memory constraint. The sum of
bloom filters sizes should be less than or equal to the fast memory size in the switch.
The second is we need to bound the number of hash functions. We let all the bloom filters in one
switch share the same group of hash functions so that the CPU calculation time is reduced and
we also bound the number of hash functions in this group.
We proved that this optimization problem is convex. So there exists an optimal solution. And it
can be found by the interior point optimizer solver. So for evaluation we take a forwarding table
with 200 K entries and 10 next hops. We bind the hash function to be used in the switch as eight,
and from the figure we can see that we need 600 kilobytes of the memory to reach an overall
false positive rate of .001 percent. And we compare our memory with hash tables, we can see
that if we keep the overall false positive rates at .1 percent then we can save 65 percent of the
memory.
And with the increase of the forwarding table entries, the gap becomes larger. So since we've
already reduced the false positive rates, now how to handle this package that is apparent false
positives. We can easily detect a packet experienced false positives if it matches multiple bloom
filters in the switch. So our goal is to not multiply the packet and we do not need to refer to the
slow memory to handle the packet. And we can deliver the packet in a timely fashion.
So BUFFALO takes two approaches to handle these packets. The first is that it avoids standard
packet back to the user interface where it comes from so that this simple technique can
guarantee that there is not -- no loops in one false positive case. And if there are multiple false
positives experienced by the packet, then we use random selection among all these measured
next hops, and we can guarantee the reachability for these packets.
Here's more detailed discussion. We first discuss the one false positive case which is the most
common case. That means that the package only experienced one false positive in one bloom
filters in the network.
So, for example, in this figure, switch eight, when a packet reaches switch eight, it matches two
next hops. The first next hop is the correct one, which leads to the shorter pass routing.
And also the packet matches bloom filters for next hop. So there's a false positives for this bloom
filter. Since we randomly select from these two matching next hops, we may select the B and
forward the packet to B, due to a false positive.
So since we assume there is only one false positive in the network, B will behave correctly. So
what will B do? B will be -- the first case is that B can -- B has a shorter path to the destination
without going through A. So it will send the packet directly to the destination.
So this A/B destination pass is slightly longer than the shortest path. A worst case is B believes it
should reach the destination through A, so send a standard packet back to A. And then in A we
still have two matches, two matching next hops. But this time, since A will avoid, send the packet
back to the incoming interface, it will send the packet directly to the shortest path to the
destination.
So we can prove that a packet will experience at most a two-hop loop if there's only one false
positives and the stretch is less than or equal to the length from A to B and from B to A, plus from
B to A.
Now we consider multiple false positives. To handle multiple false positives we will randomly
select from all the matching next hops. This can be viewed as random work on the shortest path
tree to the destination, plus a few fall positive links. And based on random work theory, we can
guarantee that the packet will eventually find a way to the destination.
And we also prove that the expected stretch with K false positives is the most at the order of K
squared times 3K over 3.
This stretch bound is actually not bad considering the fact that we use different group of hash
functions for different switches. And these false positives on different switches are independent.
And K false positives for one packet is very rare. The probability of K false positives for one
packet decreases exponentially with K.
So this stretch is not that bad. And we have some numerical starting in the campus networks that
has more than 1,000 switches. And we fix the false positives rate at each bloom filter as a fixed
value.
For example, the green line -- sorry, in this figure the access is the stretch double-ized by the
shortest path lengths and Y axis is CDDF [phonetic]. The green line shows a false positive rate
of 0.001 percent. And in this case 99.9 percent of the packets has not any stretch.
And as for the tail, there's only three out of a million packets have a stretch as long as the
shortest pass lengths. Even though when we fix the false positive rate as large as .5 percent for
one bloom filters, only two out of a million packets have a stretch six times as long as the shortest
lengths.
Note that in the campus network the shortest path length is not very long. So six times is -- the
tail six times is still not a bad result.
Finally, we discuss how do we handle the routing dynamics. Bloom filters is not, cannot be used
to delete an element from a set [phonetic] so there's an extension of counting bloom filters which
can handle the adding or deleting elements. But it takes more memory than the bloom filters. So
we use the counting bloom filters in the slow memory to handle the feed updates.
Since counting bloom filters is in a slow memory we can have a very large area for it so that its
false positive rate is very low. And then we can contract the counting bloom filters into a small
bloom filter in a fast memory. For example, in this figure all these blue cells are contracted into
one blue cell in bloom filter, and then these four white cells are contracting to one cell in the
bloom filter.
And when routing changes happen, if we want to add a route to this counting bloom filter, we add
the counters in the corresponding position and then change the bloom filter, the related cells in
the bloom filter.
We need to currently reoptimize the bloom filter size based on the counting bloom filter size when
there are large routing changes. For example, this bloom filter of size two becomes four. So we
want to expand it to size four. But it's hard to expand it directly from the bloom filter because it
already loses information.
So the nice thing is that we have a counting bloom filter in the slow memory. So it's very easy to
contract this counting bloom filter to size four -- to a size four bloom filter.
Note that this reoptimization is taken only currently like once a day or several days, because large
routing changes happen not that often. So we build a BUFFALO switch prototype in the kernel
network click. We implement the bloom filter data structure in the fast memory and when the
packet comes to our query or these bloom filters and generate the matching next hop set and we
use a false positive handler to handle the packet, to find out which next hop to forward the packet.
BUFFALO doesn't change the control plane which routes the routing protocols. So when routing
updates happen the control plane will generate the fee updates and then the counting bloom filter
in the slow memory will change correspondingly to these updates and also generate the bloom
filter updates to the related bloom filters.
We evaluate our prototype in the 3-gigahertz zero machine and it has two megabytes or two data
cache. This is viewed as the fast memory size in our optimization problem. And our forwarding
table have 200-K entries and 10 next hops.
The peak forwarding rate in our prototype reaches 364-kilo packets per second, which means we
need 1.9 microseconds to handle each packet. And it's 10 percent faster than the hash-based
solution in the switch which is existing element in click.
This, of course, the hash-based solution cannot fit the forwarding table into the L-2 cache. We
also evaluate prototype performance with fee updates. It takes 10.7 microseconds to update the
counting bloom filters and the bloom filter base for one route update.
And to reconstruct the bloom filters based on counting bloom filters it needs .47 seconds. Since
this reconstruction can be executed in another core without disrupting the packet lookup with the
old bloom filters, and then when the construction is done it can be swapping to the new -- we can
swap in the new bloom filter very fast.
In conclusion, BUFFALO improves the data plane scalability in this back network. It's
complementary to recent Internet advances in the control plane. There are three nice properties.
The first is that it reduces memory requirement compared to hash-based solution. And the
second is with the growth of the forwarding table, BUFFALO only gradually increases stretch
rather than crash or perform poorly.
Finally, BUFFALO acts quickly to routing updates. Our paper is submission to [inaudible] is
available as a link. And we have a preliminary work in workshop which uses bloom filter to
reduce the memory for enterprise edge routers.
As for future work, we are interested to use our random work theory to reduce the transient loop
or SPF. Thanks.
[applause]
>>: I just have one question. Can you go to slide 16? I think it's 16. So the first is, what's the
largest flat network you've seen? You've chosen a number like 10 hops, right? What's the
largest scale you've seen or you know about?
>> Minlan Yu: In a campus network, we evaluated this network. It has 1,600 switches. And we
assume that it used bad addresses [phonetic].
>>: Back to 16. I actually didn't understand exactly how this works, if you have multiple false
positives. You talked about the properties. But could you just walk me through ->> Minlan Yu: So, for example, this switch has a false positive. In the bloom filter that represents
next hop for this node. Then we just add a link from this node to this node.
>>: In the previous slide, No. 15, when you actually described this, you said: Well, we go to B
and you've got -- you go back to A and the next one and then you get the shortest span and
alternatively B goes to the next destination if it knows the destination.
>> Minlan Yu: Yes.
>>: Expanding that, I'm assuming ->> Minlan Yu: So dealing with these two cases are using two different techniques.
>>: Okay. So what is the technique here? I didn't get that.
>> Minlan Yu: The technique here is we first generate the shortest path tree and then we add a
few links based on the false positives for the packet.
>>: The techniques for the analysis as opposed to techniques for the handling.
>> Minlan Yu: The handling is simple. We just randomly select it. We try to analyze what's the
strategy we can get from this random selection.
>>: So we do random selection. Then you get this property, you can actually -- you get ->> Minlan Yu: So by random selection, you can just view it as we send packets based on this
graph. But there's some loops. So it was a stretch, if we randomly go ->>: It gets worse as the scale increases?
>> Minlan Yu: Yes.
>>: Unbounded somehow?
>> Minlan Yu: We bound it based on K. But if there's more switches in the network, then they're
more likely that multiple switch, the false positive of K false positive becomes larger, right.
>>: So then the evaluation with 10 hops, is that a good number to pick, perhaps? That's why I
ask.
>> Minlan Yu: For this case we don't -- we evaluate -- sorry, for the tap in table 4 we evaluate the
bloom filter performance in one switch. But here we evaluate performance in the network. So
different nodes may have different number of hops based on the topology.
>>: So for this false positive thing, can you change the units around for me so that I understand
how much longer I can keep my router, as more -- in terms of the -- like if I buy a router now,
okay, we've scaled the DCAMs or whatever or switch or whatever, however. We scaled it such
that it's good enough for however many years, what is the equivalent -- what does this -- how do I
read that graph in terms of that sort of metric?
>> Minlan Yu: Let me see if I have that figure. So in this one we fix a way -- we experiment on
one switch. And we fix the fast memory size for that switch and then we increase the forwarding
table entries. So we can see all the false positive rate how it goes.
>>: Okay. What was the -- where was the clip? Was it like after .1? When did things start going
really bad?
>> Minlan Yu: If we take the two megabytes fast memory case and for the one million entries,
then the false positive rate is point -- a little larger than .1 percent. Still tolerable.
>>: That's tolerable. But one percent is bad.
>> Minlan Yu: So it's pretty good, this number of entries, we can still handle it very low.
>>: What's the today number of No. 42 [phonetic]?
>> Minlan Yu: The one we take is 200 K.
>>: So that's Internet scale?
>> Minlan Yu: Yes.
>>: Looking at whether you're worried about each individual packet, or whether you're worried
about the extra load, sending these packets with extra pounds on the network, the latter,
unfortunately in the enterprise even above one percent, isn't too bad. But it's a little bit of extra
load, particularly if you think in the network's position you take one percent of the packets and
accepted them [inaudible] more like sending -- and then it gets to a question whether you think
the extra stretch is a big deal or not.
>>: So I guess that's a moving target in terms of where that clip is, where you would need to get
a new router.
>>: Yes, I think the whole point is sometimes you can stave it off, because you can afford to
gracefully expand your packets another stretch without running out of memory. You start to
experience extra load on the network, some degradation of the performance but it's somewhat
smooth.
>>: Okay.
>>: Thanks.
[applause]