Quality of User Experience (was RE: image stream routers)

Sat Sep 17 06:55:05 UTC 2005

Thanks for the thoughtful response.

One of the network architecture issues I'm always trying to gauge and get my
arms around is what I'll call, "Quality of user experience."  In other
words, what mix of network hardware, software, customer support, and
management will create a perception that the network is performing at
maximum efficiency.

Although the perception of network performance is entirely subjective there
are some factors that I'm sure we can all agree contribute to overall
satisfaction...i.e.

-WAN link latency.
-Packet Loss.
-Consistency in packet generation/serialization (A packet always enters
interface A and leaves interface B in .5 ms)

So, if all other elements (software, customer support, and management) are
equal, what router hardware architecture will contribute to a positive or
negative user experience?  In other words, if the routing device between my
workstation and server is a Juniper M7 instead of Pentium IV running
unix-flavor-of-the-day, how will that affect the quality of user experience?

Thank you,
Christopher

-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
Lincoln Dale
Sent: Friday, September 16, 2005 11:18 PM
To: Christopher J. Wolff
Cc: nanog at merit.edu
Subject: Re: image stream routers

Christopher J. Wolff wrote:
> I'd be interested to know the relative pros and cons of switching packets
in
> software (Imagestream) versus handing them off to a dedicated ASIC (Cisco,
> Juniper)

[without having looked at Imagestream in any way, shape or form..]

it would be _unlikely_ that any router vendor that wants to support >OC3 
could do so with the 'standard' (non-modified) linux IP stack.  if they 
are modifying the 'standard' linux IP stack then its very unlikely that 
one could do so without having to publish the source-code to it.  (i.e. 
as per GPL).

'standard' linux on standard hardware isn't capable of much more than 
100K PPS.  sure - some folks have a few hundred packets/sec - but these 
are minimalist versus the demonstrated performance of ASIC-based 
forwarding, typically 30M-50M PPS.

one advantage of software is programmability.  if there is a bug you can 
fix it.
if there is a bug in an ASIC, it may or may not be possible to fix it - 
it depends on awful lot on how the ASIC is built (whether its 100% fixed 
functionality or supports limited programmability in various stages of 
the forwarding pipeline).
it may be that its not fixable but that the ASIC allows 
software-workarounds - in essence, 'fixing' something by diverting it to 
a (slower) software-path.

note that there is a correction to make here: not all routers _ARE_ 
ASIC-based for forwarding.  in fact, most of the Cisco /router/ product 
portfolio isn't hardware-forwarding based.  generally speaking it isn't 
necessary - UNTIL you get to the point of having interface speeds & 
number-of-interfaces which exceed the capabilities of general-purpose 
processors.  that is, typically somewhere between 100K PPS and 1M PPS.

cheers,

lincoln.