[Paper] B4: Experience with a Globally-Deployed Software Defined

Sun Aug 18 02:45:30 UTC 2013

On Sat, Aug 17, 2013 at 8:08 PM, Avi Freedman <freedman at freedman.net> wrote:

> > On Sat, Aug 17, 2013 at 2:32 PM, Avi Freedman <freedman at freedman.net>
> wrote:
> > > OK, so it was horrible expect scripts but it worked.
> > Not really.
>
The idea of centralized decision makers doing something (typically
> per flow) has been proposed, in my experience, by those with little
> operational experience or those with extraordinarily constrained
> topoligies, types of traffic, and usually external filtering to
> constrain the types of traffic one could face.
>

Flow controllers are for constrained topologies.   You have some
interesting problems,  if you decide to try to bring flow controllers into
a carrier network, and have them  processing flows coming in from an
unprotected network.      How do you feel about a few billion flows per
second,  thanks to  the attacker's randomized source IPs and port numbers?

You might very well have to  "constrain the topology"  by  having a
capability to provide a flow entry for the destination IP address, and
associating all the traffic with just one  "flow".

> closely tell me about when I ask a few times/year) to actually
> deal with the every-packet-is-a-flow problem we saw first with
> 7206VXRs and that remain a real possibility for Internet-
> connected networks.  Distributing flow controllers and making
>

The centralized controller doesn't work well  in topologies  where you
cannot take the first packet --   setup the flow tables on the devices,
 and keep further control traffic limited in number of messages and limited
in number of bits.

You need a network path for control traffic,  you need CPU capacity for
your flow processing --  and there will always be RTT latency and various
other penalties   incurred by extra overhead to reach a remote controller
that is  geographically  farther away  from the route processor since the
speed of light is finite,  and any centralized controller will have finite
capacity...

Having all the flow processing on central controllers is the opposite of
load-balancing ---  it is concentration of a distributed load;   which is a
recipe for creating a capacity bottleneck on the controller and  on all the
devices that have to have  uncongested paths to the controllers...

It's a similar idea  to storing  part of your router's RIB on a hard disk
or magnetic tape,  because RAM is so expensive ----  you're going to
increase the forwarding delays of some traffic,  or some connection
initializations by doing so.

Therefore;  the only flow controller  that really makes sense in all
situations is eventually going to be one   that can download  its entire
state  into every router ---    that is:  A route controller program built
into every router and switch   (even if defined by software).

Such a product for SDN doesn't exist yet?  -- other than traditional
networking devices which don't allow you to implement an API and download
arbitrary code to them  in a vendor-independent way.

It seems like there is still a lot of work  and standardization for vendors
to be doing,   before a majority of  ISP networks could consider using SDN
 anywhere.

> So it seems to be of use only for very tiny networks or for
> very constrained and filtered or non Internet-connected topologies.
>

Yes.    That seems to be where the greatest benefits of current SDN
products could realistically be experienced at the present time;  small
filtered and private topologies,  where the controller as a bottleneck risk
is minimal.

> > in software running outside of the devices that perform the forwarding.
>
> That said, I wince every time someone starts talking about (not suggesting
> you are here but many do) making the routing engineer or designer in a box
> that sits on the bottom or besides the network.
>

I don't know --  if you make a box that can help configure your network;
you'll still need a routing engineer to setup and maintain that box,  make
sure it continues to work properly, spend all day on hold waiting for
support  to help get your network back online,  and diagnose  things when
an inevitable bug crops up and starts  costing more damage than money saved
by deploying the magic box.

I think innovation is great but I don't think there are that many shops
> that are better off writing their own control pane (centralized,
> distribtued,
> whatever) right now.
>

Yes.   Most would have no business trying to write their own control plane.
Not too long ago someone wrote about  "Tempering your MacGuyver" streak.

Which is exactly what should apply here;  SDN is something to learn about
developments in, and  one of those new flow controller schemes could be
used in a pinch as a way around certain problems  ----  new tech doesn't
mean it's somehow better,  or somehow magically defeats inherent  physical
 or computational problems.

Otherwise Rule #1 of building reliable infrastructure -- is use time-tested
technology in well-understood  vendor supported configurations in every
instance,  except in the situations where there exists compelling
justification to vary.

Flow controllers won't belong on everyone's network  just because they're
new tech  --  until they have more to offer,  it would be the exception to
the rule that you should want one.

> It's worth remembering that Google is a software company.  They are far
> ahead in software defined everything.
>

It could be interesting if Google released some of their sw and sw/hw
solutions I suppose.      Of course there are likely to be people copying
them in such case,  because  of a perception (true or false),  that  using
SDN tech early on is part of their success story.

> When I look at most of the non-Google big guys, SDN means pushing the
> vendors for better control plane instrumentation and ability to program
> (but more on the instrumentation side as where the gaps have been), and
> potentially to get some cross-provider way of doing the above.
>

That bit is the most useful.    Network devices have notoriously poor
control plane instrumentation and programmability;   SNMP and Netflow have
their limitations.

Improvements in these areas are valuable in their own right.

--
-JH