Comments on: Things I Would Like to Change Part 1/N http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/ Data Centers, Virtualization, and Cloud Computing Sun, 02 May 2010 01:04:25 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Douglas Gourlay http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-51 Douglas Gourlay Sun, 26 Jul 2009 21:19:35 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-51 hahah, how true Dave. I got so used to using the term EtherChannel over the years I must concede the point. I think I may have to write a post on proprietary versus pre-standard tonight - always a flame-ridden topic :) hahah, how true Dave. I got so used to using the term EtherChannel over the years I must concede the point.

I think I may have to write a post on proprietary versus pre-standard tonight – always a flame-ridden topic :)

]]> By: David Newman http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-50 David Newman Sun, 26 Jul 2009 19:57:02 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-50 Oh, and one other thing: It's pronounced "link ag-gre-ga-shun." No more of this proprietary lock-in nonsense... cheers Oh, and one other thing: It’s pronounced “link ag-gre-ga-shun.”

No more of this proprietary lock-in nonsense…

cheers

]]> By: David Newman http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-46 David Newman Wed, 22 Jul 2009 23:38:29 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-46 Thanks for bringing up the hashing issue. I've watched various switches and routers stumble on this for at least 10 years, and cowrote RFC 4814 as a starting point in describing the problem. When vendors respond with hand-waving about "not real world" conditions of using lots of pseudorandom addresses, my stock response is that vendors don't get to decide what addresses their customers will use. As to your load balancing question: I hope more vendors will take at least your options 1 and 2 into consideration, and on option 1 will use more L2-L4 and possibly L7 criteria in making hashing decisions. dn Thanks for bringing up the hashing issue. I’ve watched various switches and routers stumble on this for at least 10 years, and cowrote RFC 4814 as a starting point in describing the problem.

When vendors respond with hand-waving about “not real world” conditions of using lots of pseudorandom addresses, my stock response is that vendors don’t get to decide what addresses their customers will use.

As to your load balancing question: I hope more vendors will take at least your options 1 and 2 into consideration, and on option 1 will use more L2-L4 and possibly L7 criteria in making hashing decisions.

dn

]]> By: Big Surly Guy http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-39 Big Surly Guy Fri, 17 Jul 2009 03:55:13 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-39 An interesting method may be to use dispersion routing. Basically, you have a number of routes between point A and point B. Now map flows between A and B according to some hash, or round robin. If a link congests, select a couple of flow(s) and remap a couple to under utilized links. It's imperfect, but it breaks some polarization issues (InfiniBand suffers the same fate due to not having a priori notification of high volume flow polarization). You can also throw ECN into the mix as well, ie set TCP ECN, move flow hash and resume - if it's a high volume flow latency isn't likely an issue unless you drop frames ;^) If flow counters (Netflow) could be maintained and interrogated that may be a cool way of detecting high volume flows and deal with those selectively. BSG An interesting method may be to use dispersion routing. Basically, you have a number of routes between point A and point B. Now map flows between A and B according to some hash, or round robin. If a link congests, select a couple of flow(s) and remap a couple to under utilized links.

It’s imperfect, but it breaks some polarization issues (InfiniBand suffers the same fate due to not having a priori notification of high volume flow polarization). You can also throw ECN into the mix as well, ie set TCP ECN, move flow hash and resume – if it’s a high volume flow latency isn’t likely an issue unless you drop frames ;^)

If flow counters (Netflow) could be maintained and interrogated that may be a cool way of detecting high volume flows and deal with those selectively.

BSG

]]> By: Douglas Gourlay http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-38 Douglas Gourlay Thu, 16 Jul 2009 19:44:45 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-38 yes you did. I can't remember whether you were running the network at Broadcast.com then or Yahoo! but it was in one of our first meeting together in 2000/2001. :) and there is an opportunity for someone to still fix it.... yes you did. I can’t remember whether you were running the network at Broadcast.com then or Yahoo! but it was in one of our first meeting together in 2000/2001. :) and there is an opportunity for someone to still fix it….

]]> By: Darin http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-37 Darin Thu, 16 Jul 2009 19:39:23 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-37 Did I ask for this years ago? :-) D. Did I ask for this years ago? :-)

D.

]]> By: Douglas Gourlay http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-36 Douglas Gourlay Thu, 16 Jul 2009 19:33:06 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-36 because with the chipsets we were dealing with on the c6k it was not possible. Also with the transistor density and number of counters necessary if you assume a counter per bucket and per link it would be a very large number of counters that would be necessary. Some folks also worried, although never validated, that at the point of re-allocation of a bucket you could cause out-of-order frame delivery. I felt that this could be easily overcome with a PAUSE frame or minor hold-down. dg because with the chipsets we were dealing with on the c6k it was not possible. Also with the transistor density and number of counters necessary if you assume a counter per bucket and per link it would be a very large number of counters that would be necessary. Some folks also worried, although never validated, that at the point of re-allocation of a bucket you could cause out-of-order frame delivery. I felt that this could be easily overcome with a PAUSE frame or minor hold-down.

dg

]]> By: Dustin http://www.douglasgourlay.com/blog/2009/07/things-i-would-like-to-change-part-1n/comment-page-1/#comment-35 Dustin Thu, 16 Jul 2009 19:29:10 +0000 http://www.douglasgourlay.com/blog/?p=52#comment-35 How come every time I asked for number 2 you said no way? How come every time I asked for number 2 you said no way?

]]>