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...

The agr(4) man page hints at the issue.  The problem is that you 
*really* don't want TCP segments from a single connection arriving out 
of order.  While TCP semantics guarantee that things will work, it will 
cause a tremendous performance hit.  In particular, if a sender 
receives 3 duplicate ACKs in a row, it slams its congestion window shut 
and restarts the whole slow start business.

Cisco's orginal implementation did do load-balancing, as you suggest.  
They learned the hard way why that was a Really Bad Idea.

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