[c-nsp] Troubleshoot UDP out-of-sequence

Walter Keen walter.keen at RainierConnect.net
Mon Sep 12 19:56:06 EDT 2011


Sorry for coming in late in the thread, but If you control both the 
source and destination of the traffic, you could consider some sort of 
encapsulation within another protocol, perhaps ipsec, but again, that 
does delay the data, essentially with the encapsulation and 
decapsulation time, but *might* give you more control as to keeping it 
in order.  However if all of the UDP data is currently taking the same 
path to get to the destination, just arriving out of order for some 
reason, this likely will not help.


On 09/12/2011 04:47 PM, Persio Pucci wrote:
> I'd like to thank you all for the input, although it really did not help
> much on getting those ducks in a row... :)
>
> This multicast stream is for market data, flowing from Brazil to the US, and
> although UDP was really not designed to ensure ordered, error-free packets,
> it looks like that the people who designed the market data protocols either
> missed it or did not consider the traffic going overseas, for one.
>
> The bad part is that I believe my customers (and the boss) won't take
> "that's how UDP works" for an answer. Although there's TCP Replay for the
> multicast streams, it is somewhat "delayed" from the realtime data and that
> puts them behind other competitors.
>
> On Mon, Sep 12, 2011 at 6:45 PM, Nick Hilliard<nick at foobar.org>  wrote:
>
>> On 12/09/2011 21:08, Lamar Owen wrote:
>>> Quoting RFC 768 (User Datagram Protocol):
>>> "This protocol  provides  a procedure  for application  programs  to
>>> send messages  to other programs  with a minimum  of protocol mechanism.
>>> The protocol  is transaction oriented, and delivery and duplicate
>>> protection are not guaranteed.  Applications requiring ordered reliable
>>> delivery of streams of data should use the Transmission Control Protocol
>>> (TCP) [2]."
>> I would be interested to hear your opinion on how tcp over multicast would
>> work.
>>
>> But I agree with your general point that it's a bit much to expect an
>> application to work where it depends on intercontinental multicast to work
>> flawlessly and where the upper levels of the application don't even
>> tolerate out of order packets.  "Be liberal in what you expect.  Be
>> conservative in what you send".
>>
>> Nick
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


More information about the cisco-nsp mailing list