FW: [c-nsp] Cisco Gigabit EthernetSwitch Module (CGESM)fortheHPBladeSystem

[christian.macnevin at uk.bnpparibas.com]

Storm control is something I'm very wary of. The reason is that it has no 
concept of what packets it would like to drop,
and it doesn't respect that the majority of financial multicast 
implementations use reliability mechanisms to guarantee delivery.
This is implemented in the form of 'negative acknowledgement' packets 
flowing via unicast back to the source under
the common Tibco implementations. The problem is, the reply is via 
multicast.

So let's say you limit your machine to 10% of the total link bandwidth as 
multicast, to force it down to 100Meg. Nice one.
Let's now say it tries to start sending 101 Meg. Your switch starts 
dropping 1% of all packets. Which 1%? Who knows? So
your clients all now start NAKing to retrieve the packets they've missed. 
The bandwidth utilisation goes up on the server, and the
whole network. So the server starts retransmitting. But some of those 
packets are also dropped. So all the clients keep NAKking,
and because the switch is *randomly* dropping, some of the retransmissions 
get dropped, and some of the new stuff gets 
dropped. So what you get eventually is the bandwidth slowly climbing (or 
not so slowly) until every single link utilising that source
reaches its own storm control limit. What have you got? A great bit 
expensive random bit throwing evil mess that you used
to call your multicast network.

This is my fear with storm control. If anyone's online that has experience 
with it working fine in a Tibco or similar deployment, I'd
appreciate knowing what mechanism there is to stop the implosion.

And you can't raise a case with the TAC. They don't own the product - 
*everything* has to go through HP.

Cheers
Christian





Internet
lists at hojmark.org
Sent by: bulk at hojmark.org
10/10/2005 21:07

To
Christian MACNEVIN, ltd
cc
cisco-nsp
Subject
RE: FW: [c-nsp] Cisco Gigabit EthernetSwitch    Module 
(CGESM)fortheHPBladeSystem






> These are potential multicast sources. If we have sources
> multicasting above 100 Mb, then we need to have all the sinks
> running gig as well.

If you want to limit multicast, then limit that, not the link
speed. For example, look at 'storm-control'.

> The buffer overflow is occurring on both switches in the
> enclosure, and it's happening with only 1.15Mb of mcast
> traffic.

You really should contact TAC about that. It's certainly not
normal.

> Did anyone who's deployed these test them very much?

I've tested them for a customer, which now have (I think) 12 of
them in production. We've only seen minor stuff, nothing major.

-A



This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in
the United Kingdom.

BNP Paribas Securities Services London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services 
Authority for the conduct of its investment business in 
the United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority