All,
If you got 403's when trying to access the links
on http://puck.nether.net/cisco-nsp/ i've fixed that.
I'll get real links on the pages so people can view the documents
instead of using the specific urls in a few...
- Jared
On Mon, Feb 12, 2001 at 12:00:25AM -0000, Frank Bruce wrote:
> Jesper,
>
> Nice sig, actually we do believe it to be a issue, in doing CEF feature
> testing we too discovered we could support sending packets out of sequence,
> and the knock on effect to the end applications, not just voice & video.
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/ios112p/gsr/
> cef.htm#xtocid2626427
>
> Please see http://puck.nether.net/cisco-nsp/packet_reordering1.pdf this is
> an IEEE document and
> http://puck.nether.net/cisco-nsp/Router_Arch_WP_129-31.pdf a Cisco white
> paper on the subject of architectures, these are in the public domain.
>
> >Juniper also said they will come out with a solution where the Packet
> >Director will ensure that all packets in a flow will always go to
> >the same I/O manager/SFM thus there will be no packet reordering.
>
> On the 160 if the Packet Director has the task of receiving the inbound
> packets from the physical interface and deciding which of the four planes to
> send them to. Since none of the forwarding engines have had a chance to see
> this packet yet, then the Packet Director has no way to make an intelligent
> decision as to which of the four planes to send the packet to. In
> particular, it cannot know which output port the packet will ultimately be
> sent to.
>
> Next the Packet Director must make sure the 10G of received bandwidth is
> equally split to each of the four 2.5G planes, otherwise basic throughput at
> 10G won’t be achieved, and that the Packet Director has no visibility to the
> traffic on other linecards, and in particular has no means to collaborate
> with other Packet Directors in making its decision.
>
> So we are assuming that all the line cards are replaced, hence back to the
> topic we trash them.
> (after we replace it with "something better than you're used too" and pay
> freight of course).
>
> Regards
>
> Frank Bruce
> Consulting SE, NSP West
> Cisco Systems Ltd
> ---------------------------------------------------------------
> | | | 3 The Square, Stockley Park
> :|: :|: | Uxbridge, England. UX11 1BN
> :|||: :|||: | Office : +44(0)20-87568000
> .:|||||||:..:|||||||:. | The Views Expressed Are My Own
> C i s c o S y s t e m s | And May Not Reflect Cisco's
> ---------------------------------------------------------------
> All Cisco technical support should be conducted via the TAC.
>
> How to use the Cisco TAC
> http://www.cisco.com/public/support/help.shtml
> TAC Newsletter
> http://www.cisco.com/public/news_training/itsnews/subscribe.shtml
>
>
> From: Jesper Skriver [mailto:jesper@skriver.dk]
> Sent: Monday, 12 February 2001 1:07 AM
> To: Avi Freedman
> Cc: Daniel L. Golding; Randy Bush; Terence; Juniper nsp
> Subject: Re: Secondhand, Offlease, Etc.
>
>
> On Sun, Feb 11, 2001 at 12:02:11AM -0500, Avi Freedman wrote:
> >
> > Sigh, reminds me of when Sun used to landfill old 3/50s they took in
> > trade instead of doing something useful for nonprofits.
> >
> > This is different, of course.
> >
> > So Juniper has a "use m5s instead of 7206s" program and Cisco has
> > the "Juniper buyback". I guess we all benefit from this somehow?
> >
> > Anyway, on-topic:
> >
> > My understanding of the "packet reordering" issue is that Juniper
> > claims that it can (not will) only happen if there's only one
> > flow going across the whole router. Is this essentially correct?
>
> That's not what I heard, I was told it could happend in corner cases
> where 2 flows had common ingress and egress interfaces, one flow only of
> small packets, and one only of larger packets.
>
> But the real issue here is, is it really a problem, I'd say not.
>
> Juniper also said they will come out with a solution where the Packet
> Director will ensure that all packets in a flow will always go to
> the same I/O manager/SFM thus there will be no packet reordering.
>
> /Jesper
>
> --
> Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
> Work: Network manager @ AS3292 (Tele Danmark DataNetworks)
> Private: Geek @ AS2109 (A much smaller network ;-)
>
> One Unix to rule them all, One Resolver to find them,
> One IP to bring them all and in the zone to bind them.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT