On Feb 19, 2008 4:28 PM, David Williamson <[EMAIL PROTECTED]> wrote: > A simple approach might be to try to stripe UDP traffic across all > available paths. I hope it is obvious why this is a bad idea with > real-time traffic.
For UDP, clearly a lot depends on the application. In general, L4 multihoming/mobility should work well for UDP too, so long as the flows are congestion controlled, and so long as the delay of the slowest path is acceptable. For non-congestion controlled traffic, there's no control loop to react to congestion and cause the apps to move the data to the other paths. You can probably get crude balancing, but there's nothing to reduce the overload on the congested paths. Likely any crude congestion control would be sufficient to get benefits though if the flows are long-lived. For real-time traffic, the real question is one of delay, not reordering. Such apps need a playout buffer anyway to remove jitter, and this should remedy reordering too (if it doesn't already do this, various wireless links will badly affect your apps). For streaming media, there's no real problem, but for interactive real-time apps, the effects of the jitter buffer are effectively to increase the delay to that of the slowest path. The likely solution would be to have a delay threshold, and only use paths that are less than that threshold. However, there are a lot of unanswered questions about the stability of such solutions. Only research will tell what the best solutions here are. Cheers, Mark -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
