& cplSiteName &

IPv6 Routers Get a Run-Through

Light Reading
News Analysis
Light Reading
2/26/2003

A recent test of routers designed to handle Internet Protocol (IP) version 6, an improved version of the protocol used for Internet traffic, highlights progress and the need for further development.

Results of the test, which was conducted by BII Group, a Beijing-based institute that's led the charge on rolling out a commercial IPv6 network in China, are presented and summarized in a new Light Reading report (see IPv6 Router Test).

By and large, the IPv6 routers in the test conform with key standards, they interoperate with each other, and they deliver good performance in most circumstances. But there's clearly room for improvement.

In his report, Hua Ning, BII's CTO, studiously avoids criticizing vendors or their equipment and says the tests weren't intended as a performance comparison anyhow. All the same, the results invite such comparisons, which are undertaken in Light Reading's report, culled from Ning's results.

Conducted with equipment from Agilent Technologies Inc. (NYSE: A), the test included the M20 from Juniper Networks Inc. (Nasdaq: JNPR), as well as the following routers from Japanese vendors that have focused on enhancing their wares to deliver high performance when handling IPv6 traffic:

By demonstrating the availability of high performance equipment, the test adds to the momentum building behind IPv6. And of course, that raises a question: Why didn't Cisco Systems Inc. (Nasdaq: CSCO) participate in this test? A Cisco spokeswoman told Light Reading today (Feb. 26) that "the request to support the Beijing Internet Institute test came in too late for Cisco China to pull together the equipment and prepare the test bed, so we had to decline."

The test also points to the need for further development work among router vendors. In particular, the maximum number of routing table entries handled by the Japanese equipment is very low. And some of the routers also appear to struggle when handling floods of small packets.

It could be argued that vendors have got plenty of time to address these points. The amount of IPv6 traffic at Internet exchange points is still very low. Still, service providers need to think ahead when they're buying core routers – and IPv6 traffic volumes could explode in the coming years, as wireless access to the Internet takes hold. This is particularly true in the Asia/Pacific region, where the shortage of IPv4 addresses is most acute.

The full report is here: IPv6 Router Test.

— Mary Jander, Senior Editor, Light Reading

Want a deeper understanding of the issues involved in integrating IP and optical technology? Check out the first module of Light Reading University's course on the topic. Click on this link to check it out for free!

(20)  | 
Comment  | 
Print  | 
Related Stories
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 2 / 2
RussJ
RussJ
12/5/2012 | 12:33:00 AM
re: IPv6 Routers Get a Run-Through
Skeptic: "I'm saying that nobody should deliberatly design a system that reorders packets period."

Ok, so right off the bat I'm going to assume you don't know what you're talking about. You're either a software guy or a marketting guy.

I thought you might get caught up in the "flow awareness" thing, but I'll try to explain.

Many network processors are multithreaded internally, and can process one packet whilst another is blocked on an external resource (such as a route lookup). Some packets take longer to process than others (e.g. one packet may be terminating an IP in IP tunnel, whereas another may be straight, simple routing). Or maybe one packet is received on an interface that has more expensive policies enabled than another interface. Point is, you want to dispatch packets out of the network processor as quickly as possible - but no quicker.

Some forwarding subsystems have the notion of an "ordering id" - packets that arrive with the same ordering id will have their egress order enforced.

So you want to assign the same ordering where it makes sense. My example was packets with the same IP destination address (not as granular as it could be, but simple enough to get your head around).

You don't want to tie up network processor and reorder buffer resources by enforcing an arbitrary rule that says, "a forwarding system is a dumb FIFO".

I'm making a general point here, and not defending Juniper (for which I have no inside info - I don't know for a fact that they don't reorder within flows). I'm just picking up on the popular misconception that packet reordering is bad. It's not bad if you understand what you're doing. It's actually very good.

Russ.
AAL5
AAL5
12/5/2012 | 12:32:51 AM
re: IPv6 Routers Get a Run-Through
Skeptic said "Their IPv6 forwarding performance supposedly has problems."

I don't know where you heard this from but I can assure you it is incorrect.

AAL5
excitedPhoton
excitedPhoton
12/5/2012 | 12:32:42 AM
re: IPv6 Routers Get a Run-Through
Skeptic said "Their IPv6 forwarding performance supposedly has problems."

To which AAL5 replied:
I don't know where you heard this from but I can assure you it is incorrect.

To which I say:
I heard recently that their IPv6 was done in slowpath. That can't be right, can it? Even a call from Chambers wouldn't fix that.

-ep
AAL5
AAL5
12/5/2012 | 12:32:26 AM
re: IPv6 Routers Get a Run-Through
excitedPhoton said "I heard recently that their IPv6 was done in slowpath. That can't be right, can it?"

No it's not right, IPv6 is done in fast path.

AAL5


Iipoed
Iipoed
12/5/2012 | 12:32:25 AM
re: IPv6 Routers Get a Run-Through
russJ- great post, one of the few posts over the last year I really learned something from. Keep educating us.
skeptic
skeptic
12/5/2012 | 12:32:23 AM
re: IPv6 Routers Get a Run-Through

Ok, so right off the bat I'm going to assume you don't know what you're talking about. You're either a software guy or a marketting guy.
-----------

I suggest you re-read my previous message.
Going over all of this stuff in detail doesn't
change any of the issues involved in preserving
order only on a flow basis.

A system that treats things as a dumb fifo is
in the long run, much less easier to maintain
and much less fragile than systems that try
to identify and manage flows.

The slowest path through your forwarding code
(features, etc) is in the long run the performance
of your forwarding system. Most of the customers
these days are not so unsophisticated that they
are only interested in forwarding performance
with all the features turned off.

What you gain by reordering in terms of tiny
amounts of latency reductions is more than taken
away by making the packet processing difficult
and unpredictable to test/debug.

Tony Li
Tony Li
12/5/2012 | 12:32:22 AM
re: IPv6 Routers Get a Run-Through
Skeptic,

The real constraint on the system is to ensure that packets within a flow are not reordered. The system does not have to recognize flows to do this.

There is no constraint on the system that packets from different flows remain ordered. You indicate that this would make maintenance and testing easier and while that would certainly be true, you have to weigh that advantage against the implementation complexity of a strict FIFO.

That strict FIFO not only adds latency, but it increases buffer occupancy. And that has a real cost in the system design. You are making inefficient use of system resources and that shows up in the cost of the product.

By relaxing the constraint across different flows, you broaden the solution space and allow for more efficient designs. Yes, this is an engineering tradeoff, but it is far from clear that there is only one definitive, correct model.

Regards,
Tony
RussJ
RussJ
12/5/2012 | 12:32:18 AM
re: IPv6 Routers Get a Run-Through
Skeptic: "Most of the customers these days are not so unsophisticated that they are only interested in forwarding performance with all the features turned off."

Customers can be very sophisticated. Some carriers set the line-rate bar at 100-byte packets (a more reasonable goal than the holy grail of 40-bytes). Some (most?) mandate that ACLs impose no performance hit, as ACLs are always used. It's pretty clear that sophisticated packet processing such as terminating tunnels requires more oomph than a simple routing operation, and the better customers are smart enough to know what they really need and what they're willing to pay for.

Within reason it's possible to engineer something that can forward everything you throw at it at wire-speed with 40-byte packets and every feature turned on, but at the end of the day the guy who builds the router that does 80% of that at 40% of the cost is going to get the business, and all you'll be left with is an interesting science project.

Russ.
skeptic
skeptic
12/5/2012 | 12:32:02 AM
re: IPv6 Routers Get a Run-Through
The real constraint on the system is to ensure that packets within a flow are not reordered. The system does not have to recognize flows to do this.
-----------------
In order to preserve the individual flow in
order, there has to be a mechanism to identify
the flow. Granted, not a stateful mechanism,
but some means of identification.

The next step is usually some sort of static
scheduling mechanism that uses the flow
identification criteria to map sets of flows
to particular resources (threads if you will)
within the forwarding subsystem.

The problem that I've seen with this approach
is that the flow identification procedure
combined with static mapping to threads
(or parallel units) inevitably leads to
inefficent use of the parallel units. If you
say that all of certain packets have to go through
a particular computational unit in the forwarding
system (or a set of buffers), you are creating
a constraint that leads to unbalanced performance
in packet processing.

Now there are multiple different approaches that
can be taken to improve the situation. And I've
said before that I'm not saying its impossible
to build a system that works in this way, but
in my opinion it has serious drawbacks. Its
more complex and you end up with tough scheduling
issues and fairness issues rather than buffering
issues.

As far as the increase in buffering, it can be
an issue but it depends on how long the
best-case vs. worst-case packet processing
interval is. I tend to think that the interval
should be kept small, but I know there are
people with different opinions on that topic.

I agree that its an engineering tradeoff and
while I have strong opinions on the topic, I
dont intend to say that other approachs are
necessarily wrong.

Mark Seery
Mark Seery
12/5/2012 | 12:31:47 AM
re: IPv6 Routers Get a Run-Through
Skeptic,

While I don't necessary concur with your original point about a strict FIFO (because of the complexity of modern network elements, particularly large routers, you preserve order in one place just to have it break somewhere else) I do want to thank you for reminding us of the importance of looking at the "system" as a whole, and of course the network and its applications, and hence those that optimize a single component of any system or network may be missing a bigger picture.

IMHO, there is no single most optimal system for all parts of a network or system. Where there are lots (say millions) of individual flows, then simple hashes and mapping to links can work quite well. Where there is not, then sequence and spray works well, though you have the potential of increased latency, so you have to decide which you are optimizing for: bandwidth efficiency or latency, and sometimes the resequencing can be designed so there is minimal normal case impact.

But whatever combination of optimizations are chosen, solving the system level and networking level issue is more important than solving a component level optimization within a system. If a vendor wants to sell to some operators, this must be addressed; vendors have a choice of who they want to sell to of course.

RussJ,

Yes a hero test may not always be "a reasonable goal", but it is also possible to make the argument that not knowing if something will break when you turn on a new feature creates cost and complexity in your operations. Different operators will optimize accordingly, and like any market, choice is a good thing - and "unreasonable" agendas pursued by some operators may also provide a larger message to the market as a whole that is worth listening to.

-mark
<<   <   Page 2 / 2
Featured Video
Upcoming Live Events
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events
Upcoming Webinars
Webinar Archive