In message <E1EkD2n-0007GY-00@smeg.dsg.stanford.edu>, jonathan@dsg.stanford.edu
 writes:
>
>In message <20051208014223.107493C015F@berkshire.machshav.com>,
>"Steven M. Bellovin" writes:
>>In message <200512072235.RAA20918@Sparkle.Rodents.Montreal.QC.CA>, der Mouse 
>wr
>>ites:
>>>
>>>One of the most bothersome things about agr(4), to me, is that which
>>>link a packet goes out seems to depend on nothing but a hash of
>>>assorted data related to the packet.  This means that if links of
>>>different speeds are aggregated, the slower one(s) will get overloaded.
>>>I'd expect it to simply pick the interface with the shortest output
>>>queue....
>>>
>>
>>That's mostly a feature...
>
>[.. discussion of TCP reordering and vendors who got it wrong ...]
>
>Hi Steve,
>
>In fact, it's more than a feature, it's a _requirement_.
>
>IEEE 802.3ad requires that all packets (frames, in layer2-speak) in a
>flow not be reordered (or htat they traverse the same path through a
>link-aggreation group, I forget the exact wording, but the intent is
>unmistakably clear. At least to anyone with our shared backgorund).
>
Yup -- it's a requirement precisely because of the problems I outlined. 
I was speaking more poetically when I phrased it as a I did.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb