x
Optical/IP

Packet Design Intros BST

Packet Design LLC, the technology startup led by former Cisco Systems Inc. (Nasdaq: CSCO) CTO Judy Estrin, is introducing a new routing protocol that it says will help make Internet more reliable and secure. The new technology, called Border Gateway Protocol (BGP) Scalable Transport, is meant to simplify the way routers exchange BGP tables (see Packet Design Intros Routing Protocol).

A well documented Internet problem relates to Border Gateway Protocol (BGP) routing tables, the directories of where things are located on the Internet that enable big backbone routers to do their job (see Experts Sound Alarm on Internet Routing ). The Internet's growth -- and the millions of new devices with IP addresses -- has caused these BGP tables to grow to about the size of Anna Nicole Smith. Also, more enterprises and ISPs are using BGP to connect to multiple ISPs, which adds significantly to the number of BGP route table entries.

Though today's routers are extremely fast, a lot of their processor power and memory are consumed when the BGP-related information gets too big. "What's essentially happening with BGP is these massive address tables -- phone books, if you will -- are being moved from one ISP to another to another to another," says Richard Clarke, special advisor to the President for cyberspace security.

Packet Design's Estrin says BGP's problems can be addressed by changing the way BGP information is carried to the other routers in a network. Right now BGP tables are carried via TCP (Transmission Control Protocol), a protocol that makes a point-to-point connection between routers.

Enter BST, or BGP Scalable Transport, which Packet Design describes as an alternative transport protocol for BGP. TCP devotes memory to keeping track of the state of the TCP connection. But rather than keep a plethora of point-to-point links, BST works by using a technique known as "flooding" to send BGP tables only to a router's immediate neighbor routers. Those routers, in turn, send it to their neighbors, and so on. Theoretically, fewer resources are exhausted this way than keeping track of the state of so many TCP connections within a network.

BST comes as a reference source code module. The reference product contains all of the tools a router vendor would need to build and test BST in a FreeBSD (Unix) environment. BST doesn't change the BGP protocol, Packet Design says. But a router's BGP implementation would need some tinkering, so the router will use BST for message passing instead of TCP.

Estrin says there are also security benefits to this approach as well. In a BST-enabled cloud of routers, only one router at a time would have its IP address exposed to the outside world. When that one router fails, other routers would step up, one at a time, as designated by a network administrator, to take its place.

"There's a lot of focus in the Internet on making things faster," Estrin says. "What we're finding now is that we need to focus on the control plane, which allows you to make it better, not just faster."

Estrin says Packet Design aims to sell BST to router vendors and pricing starts at $100,000. This is the company's second commercial product since inception. The first was a router network troubleshooting system called Route Explorer (see Packet Design's Routing 'Spy' ).

Though the potential customer base is small, and it may be a tough sell, vendors might take solace in knowing that BST's creator is former Cisco chief scientist Van Jacobson. "As a person who has played a large role in the development of TCP over the years [Jacobson] is a credible person to address the problems of TCP," says Mark Seery, an analyst at RHK Inc.

Whether it’s a commercial success or not, the fact that someone is attempting to solve some of the problems surrounding BGP is getting some cheers. "Even if all [Packet Design] does is open up a conversation on the topic, I think [it] will have done the industry an incredible service," Seery says.

Other routing experts say BST is frivolous business. "BGP tables are big and TCP has high memory costs, but so what? Memory is cheap, and even newer edge routers are scaling to hold tables many times the size of today's full Internet table," says one routing wonk, who asked not to be named. "Also, the rate of BGP table growth is slowing." — Phil Harvey, Senior Editor, Light Reading
www.lightreading.com
beltway_light 12/4/2012 | 9:23:12 PM
re: Packet Design Intros BST
the idea sounds cool, why waste bandwidth
to update every router in the domain while
you can do "flooding" to cascade the updates?

If they think iBGP full-mesh problem can be
solved like IGP flooding, then they are
opening a can of worm here. In order to make
it really work, it probably can get even
worse than iBGP/TCP full-mesh problem.

Without TCP reliable transport, one has to
deal with ack and retransmit, one has to
keep all the packets around for long time
in order for retransmit. then to claim no
change to BGP protocol is a bogus claim.
how does BST flood over a LAN, do they need
to elect DR and BDR for that:-)

Just ask them a very simple operational
question: what if a router in the middle
of the backbone reboots, does the BST
neighbors suppose to keep millions of BGP
packets and reflood to this router? or does
every router in the domain suppose to
reflood every thing again?

sounds like a cool and broken idea to me.
skeptic 12/4/2012 | 9:23:35 PM
re: Packet Design Intros BST There is a disconnect here. Perhaps the wrong part of the technology was deescribed, or this technology does not hold a solution for the larger issues. Either way, any of this commentary / context is conspicuously absent. Perhaps PEBKAC?
--------------------
There is a data sheet at the packet design
website that is equally confusing.

mu-law 12/4/2012 | 9:23:40 PM
re: Packet Design Intros BST Surely Estrin, Van, Cengiz, all being quite smart, have read the current work on BGP (e.g. Gordon & Wilfong, et al) and its well documented issues.
What this article describes is a proprietary mechanism to address issues that have already been solved by open standards, like SCTP.

There is a disconnect here. Perhaps the wrong part of the technology was deescribed, or this technology does not hold a solution for the larger issues. Either way, any of this commentary / context is conspicuously absent. Perhaps PEBKAC?

Confused,
mu
skeptic 12/4/2012 | 9:23:43 PM
re: Packet Design Intros BST Think more of it, mulitcasting BGP updates to
all peers does not make sense. Each peer may
have different policies/filtering so that the routes you send to each peer may be different. You cannot just send all peers the same stuff.
----------------

The other thing to consider is that if you use
flooding for BGP routes, you are getting a similar
effect to redistributing all (external)
BGP routes into the IGP (OSPF/ISIS).
The historical problem with putting BGP
routes into the IGP is that the attributes are
lost. But if you flood BGP information, you
lose the attributes anyway. BGP can't do policy
modifications if you flood, so there are few
if any attributes to lose.




myresearch 12/4/2012 | 9:23:53 PM
re: Packet Design Intros BST Think more of it, mulitcasting BGP updates to
all peers does not make sense. Each peer may
have different policies/filtering so that the routes you send to each peer may be different. You cannot just send all peers the same stuff.
rainbowarrior 12/4/2012 | 9:24:01 PM
re: Packet Design Intros BST
Since when has the maintenance of TCP state machines been a gating factor in BGP scaleability?
The full mesh problem has more to do with processing sumultaneous updates from multiple peers.

I agree that Harvey must have missed the point. It sounds like Packet Design is proposing a multicast flooding technique to address the full-mesh problem.

Of course, until we see a draft on what they are proposing, we'll never know.
skeptic 12/4/2012 | 9:24:02 PM
re: Packet Design Intros BST Van has made amazing contributions... just saying that he has recently done some sloppy work and any of the "routing gods" can do bad work as well as good work.
-------------------
It wasn't just sloppy work. It was his attitude and
his unwillingness to listen to other people when
they questioned his conclusions. Sure, people
make mistakes. But when people point them out,
your supposed to acknowlege them rather than
treating the people who correct you as ignorant
or not worth of talking to.

achorale 12/4/2012 | 9:24:08 PM
re: Packet Design Intros BST Emirikol writes:

> Sorry... second sentence should have said:
>
> The world would be much easier to manage if
> people would spend more effort saying fewer
> things but saying them correctly.

this has to be the funniest post i've seen
in a long time. classic! thanks Emirikol ...

gardner 12/4/2012 | 9:24:09 PM
re: Packet Design Intros BST What is with the pentagrams around TCP? <\b>

Pentagrams? That's so cute! Evidently we have one of those guys right here in our midst who sees Anton LaVey under every bed. ;-) Pentagrams indeed. As a SONET guy I tend to think all IP heads are devil worshipers but I think those particular drawings might represent complete graphs with 5 vertices more than they represent Satan. I suppose that to the unwashed masses who were drunk that day in discrete math class they look suprisingly like an upside down pentagram contained in a pentagon but they aren't. Perhaps if you cut back on the Jack Daniels . . . ;-)
light-headed 12/4/2012 | 9:24:10 PM
re: Packet Design Intros BST Van has made amazing contributions... just saying that he has recently done some sloppy work and any of the "routing gods" can do bad work as well as good work. Time will tell with this one but i am suspicious of anything that is not pushed through the ietf standards process and subjected to peer review. This may well be a submitted draft but there is no mention in article.
techstud 12/4/2012 | 9:24:13 PM
re: Packet Design Intros BST lightheaded,

I would say that Van is one of the best in the networking industry. All his papers starting from his very influential slow-start paper in 1988 SIGCOMM are exceptionally good. I wouldn't give much credence to some researchers proving one of his paper's conclusion 'inaccurate'. Practically, every new research paper begins by discussing flaws/problems in previously available mechanisms or algorithms. So it is a very normal evolution of ideas.

I would give a very serious look to design and software of BST simply because it came from a team led by Van Jacobson.
Belzebutt 12/4/2012 | 9:24:14 PM
re: Packet Design Intros BST Now, if this is the case, they are really proposing an alternative to BGP route reflection:-)

That's what I gather too. It seems like they want to get rid of BGP's full-mesh requirement, which has little to do with TCP. This is already solved to a certain extent by route reflectors, perhaps this is a different (and maybe better) way of achieving the same result.
myresearch 12/4/2012 | 9:24:18 PM
re: Packet Design Intros BST I dont fully understand what this article is talking about. Anyone has a clue?

From what I can make out from the artile it seems that they are proposing a new transport protocol to replace TCP for BGP route distribution. If my guess is correct, you are doing multicast and maybe reliable multicast stuff.

Now, if this is the case, they are really proposing an alternative to BGP route reflection:-)



light-headed 12/4/2012 | 9:24:19 PM
re: Packet Design Intros BST Van did some great work with TCP but one of his recent drafts/rfcs in the ietf had very poor mathematical theories which were proven to be inaccurate by many of his colleagues. Lets hope that this protocol is better conceived.

who would really pay for this anyway? it should be an RFC in ietf and pass the peer review... then they can try to sell their version or others can implement their own.
skeptic 12/4/2012 | 9:24:21 PM
re: Packet Design Intros BST
Before anyone sinks any effort into working
on this, talk to some people who tried to work
with Van on RED & diffserv.

I dont think what they are proposing is as easy
as it sounds. Or they have bothered to fully
think through many of the implications of what
they are proposing.

The reason why you have individual TCP connections
for peers is that the routing information can
be altered in many different ways via policy.
And because the TCP connection provides a
coarse-grained way to know if the router your
sending information to is alive.

You can do what they are proposing, just be
aware that it may come at a price. And that
tickering around with junk software like gated
is just scratching the surface of the problems
that will probably come out of this.

But as with RED and Diffserv, I would expect
that Van will continuously claim to have all
the answers in a paper to be produced the
day after never. And that lots of other people
will end up doing the hard work of making his
ideas function.

And if this doesn't show up at IETF as at least
a draft, it should be ignored.
signmeup 12/4/2012 | 9:24:22 PM
re: Packet Design Intros BST Taken from article:
"BST doesn't force the border router to send massive routing tables to every other router in the network. Instead, a BST-enabled router would only send the necessary info to its immediate "neighbor" routers."

So, you mean revert back to a link-state protocol like IS-IS or OSPF? I'm not sure I see the logic here - however it is a lightreading article so I am sure pertinent information is left out (just kidding guys, keep up the great work <g>)....

I would be interested in seeing the research PD did and what mechanisms they plan to use for flooding.
</g>
Emirikol 12/4/2012 | 9:24:22 PM
re: Packet Design Intros BST Sorry... second sentence should have said:

The world would be much easier to manage if people would spend more effort saying fewer things but saying them correctly.
Emirikol 12/4/2012 | 9:24:23 PM
re: Packet Design Intros BST This type of article does a real disservice to the Internet as a whole. The world would be much easier to manage if people wouldn't spend more effort saying fewer things but saying them correctly.

I can't for the life of me figure out if this article is a joke. I certainly hope it is... because this article didn't accomplish anything useful. It gave no information to people who might need to be aware of developments while at the same time trivializing concerns which could be legitimate.

What is with the pentagrams around TCP? Is this article about TCP or BGP? TCP has VERY little to do with BGP. Rather than adding to the confusion and misinformation in the world, go get a book and learn something.

Or at the least... stop pretending to be an expert on something you clearly do not understand.
optical_IP 12/4/2012 | 9:24:23 PM
re: Packet Design Intros BST Sorry ......... "pouring money" is also not the right word
optical_IP 12/4/2012 | 9:24:23 PM
re: Packet Design Intros BST DARPA is pouring money into BGP research at ISI. (www.isi.edu)

http://www.fastlane.nsf.gov/se...

"Invested" may not be the word ....... but anyway

optical_IP
ceiloblue 12/4/2012 | 9:24:24 PM
re: Packet Design Intros BST "...Richard Clarke, special advisor to the alleged President for cyberspace security."

Can't you guys just admit that you lost and get off this? Or should we all look forward to "alleged Senator Frank Lautenberg, Illegitimate, from New Jersey" ??
dljvjbsl 12/4/2012 | 9:24:26 PM
re: Packet Design Intros BST Whether itGÇÖs a commercial success or not, the fact that someone is proposing a solution is a relief to technology experts. "Who owns the Internet? Everyone does, and no one feels responsible for funding this work [on underlying Internet protocols]," says Clarke.
B/b>

All of the people who attend IETF meetings and all of te academic work sponsored in this area and someone says that noone feels responsible for funding work in this area???????

Am I interpreting this correctly because I see a lot of money being invnested in this area.
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE