i ‘ d like to thank u alot for that nice forum ,, my questions are :

1- when TCP indicate that there is packet loss , is it will begin slow start phase from he very begining (1 , 2 , 4 , 8 , ….) ? or it will begin from the last window size before dropping ?

2- is there any way to overcome packet loss due to congestion ?

i know my questions may be silly but it really confuse me ..
thanks
Mina

Only called you out because you are THE MAN on this stuff.

Honored that you took the time to drop by.

.nick

I read with great interest your post; very well prepared and presented.
My objective is to learn more about TRILL, having so far mostly had exposure to the IEEE 802.1aq variant.

But before I come to TRILL I have a couple of comments…

You state:
“Cisco is the only major switch vendor to successfully engineer and support MCEC with (2) fully featured *MODULAR* Layer2/Layer3 Tier 1 switches. And NO switch vendor, not a single one, has successfully engineered, sold, and supports a (4) switch MCEC cluster of *MODULAR* Tier 1 class switches.
Disagree?”

Well, I realize you work for Cisco and Cisco’s marketing might would have you believe that Cisco invented MCEC (as you refer to it).
Yet in all fairness MCEC was invented by Nortel back in 2001 under the name Split-MLT, as any of Nortel’s loyal customers will attest. True, Nortel is a failed company but the ethernet switching product line – and SMLT – have been taken over by Avaya who seem to be re-launching that offering with new vigour. So Cisco are definitely not the only ones to offer this (unless of course you consider Cisco the only “major” switch vendor..!)
Furthermore, SMLT is still superior to vPC in many respects.

As for no other vendor engineering and supporting a 4 switch MCEC I would expect this to change when Juniper launch their Virtual Chassis on their modular platform.
Yet, in my experience, the problem you describe in figure 7 is not so much of an issue because if you need additional aggregation capacity you can always deploy additional MCEC clusters which can be interconnected together without introducing Spanning Tree and still using all links; though in your diagram this would mean that SW3 would be only connected to one MCEC cluster and SW4 to another MCEC cluster.

Coming to TRILL, I’d be interested to take your view on the pros and cons of TRILL vs 802.1aq and why Cisco is going the TRILL route.
As far as I can tell, both are very similar in that they rely on IS-IS to program the MAC tables (as OSPF does for IP routing tables).
They both address the plug & play simplicity, eliminate Spanning Tree, flatten the network (and thus reduce latency), deliver fast failure recovery, are scalable and robust.
The differences seem to be concentrated around the load balancing capabilities and the actual packet encapsulation used and the fact that one is an IETF standard and the other is IEEE.
Whereas TRILL hashes any and all traffic across all available links, SPB is more conservative and will select a unique path across the network for all traffic belonging to a same service instance. But in practice you do achieve load balancing with SPB as you provision additional service instances.
SPB seems to have a better pedigree in that it is an evolution on other IEEE standards such as 802.1ah (MACinMAC encapsulation) and 802.1ag (CFM) which were developed to for the carrier ethernet space.
The CFM one means that SPB has powerful OA&M capabilities (much like what carriers get from MPLS and ATM..) whereas TRILL seems to have none.
Essentially SPB’s more deterministic approach is a necessary trade off in order to leverage those OA&M capabilities.
So while the hashing capability of TRILL is very attractive, the downside is that having to troubleshoot a TRILL network where some conversations across the TRILL network suffer from performance degradation while other conversations (on the same edge vlans) don’t, is going to be painful.

I’m also surprised to learn that hierarchical MAC learning is not an integral part of TRILL, but rather a Cisco proprietary add-on.
With SPBM (which leverages 802.1ah MACinMAC encapsulation) this is per standard.

So it seems to me that TRILL is a bit of a messy kludge at the moment with Cisco’s first implementation adding bits and bobs which certainly make sense, but are not part of the standard and that raises questions to how interoperable TRILL implementations will be between different vendors implementing it.

Anyway, I’ll stay tuned for more..
Thanks again
John Scaglietti

Many thanks,
Paul

Great post,
Cheers

But those cables cost money and they also draw power so actually to be fair in your comparison you need to include the cost of the cables.

OK. Fine, lets add in the cost of the cables. Cisco list price for a 3 meter SFP+ copper cable is $210. Since we have already established the pass-through design saves $250 per port, if we add in the cable it’s a $40 per port savings. At the end of the day it’s still cheaper while providing a more intelligent network for the customer. Furthermore, the 10GE pass-through design is capable of FCoE, so no additional FC blade switch is necessary to provide FC connectivity to the HP blade servers. Given that each HP Virtual Connect FC module is roughly $9,000 – the 10GE pass-through design can remove around $18,000 per c7000 chassis in FC networking costs. I can assure you the cable costs are no where near $18,000 per chassis!

One of the real advantages of Virtual Connect is the ability to keep a lot on “non-essential” traffic away from the network (like vmotion) and inside the chassis where bandwidth is cheap and plentiful.

We have already established HP Virtual Connect isn’t “cheap” and the key point made in this article is that the bandwidth is NOT “plentiful”. Vmotion traffic is a perfect example. Because HP Virtual Connect has no intelligent QoS capabilites the VC administrator must carve up the 10GE link and decide how much bandwidth vmotion will get (something less than 10GE). Any bandwidth given to vmotion will not be available to other traffic types, such as VM data or IP storage. In many cases this results in the customer allocating 2 Gbps for vmotion. Compare that to Cisco UCS or the HP 10GE pass-through design where vmotion can get all 10GE of bandwidth if its available without making any compromises. Thats what I call “plentiful” bandwidth.

Do you honestly believe that CPU’s are the bottleneck in a datacenter? … CPU’s were a problem 2 years ago but there are now more than enough spare cycles to take care of the minor overhead involved in performing QoS at the hypervisor.

I never said server CPU’s were a bottle neck. What I said is that server CPU’s should be doing the job they were purchased for, to execute business applications. A server CPU cycle spent doing networking functions reduces the efficiency of the server. Furthermore, I think you missed the point completely. You can do QoS at the hypervisor all day long but if the switch port connected to that server is not capable of enforcing the QoS policy (as is the case with HP Virtual Connect) you have accomplished nothing.

Memory is no longer an issue with the advent of Nehalem-EX

Memory capacity was no longer an issue with Nehalem-EP processors, actually, thanks to the Cisco UCS B250 blade, where you have (48) DIMM slots available on a (2) socket Nehalem-EP board. There is also a Westmere-EP version of Cisco UCS B250. Sure, the Nehalem-EX architecture has more memory DIMMs and more CPU power, but at a significantly higher cost. If the customers applications are more memory bound, they have a great choice in getting the needed memory footprint at a lower cost with Cisco UCS B250 blades which are unique in the market in providing lots of memory with lower priced, lower power processors.

My understanding is that today you are limited to 10Gb active per 2 socket box?

If you are talking about Cisco UCS, you are definitely wrong there. The Cisco UCS B250 blade I discussed above is a (2) socket blade with 40 Gb active I/O bandwidth delivered from (2) dual-port 10GE mezzanine adapters.

Don’t get me wrong QoS has its place, but it shouldn’t be the primary bandwidth control mechanism in the network, it should be a tool of last resort

If you read this article you would have learned that I agree with you and that’s exactly how intelligent QoS works … it only enforces a policy when there is congestion. HP Virutal Connect, on the other hand, is the exact opposite. The rate-limiting requirement of FlexNIC’s is controlling and limiting bandwidth at all times, even when there is no congestion!

Thanks for stopping by!

Cheers,
Brad