On 09/12/2011 11:50 PM, cisco...@secureobscure.com wrote:
Or someone should be out there developing mTCP (Multipoint TCP for multicast
applications) requiring reliable delivery. There is a need for both reliable
delivery, and multicast in the case of financial etc.
Such as PGM, which was
On 13/09/2011 04:22, Persio Pucci wrote:
all Cisco gear, in the following order:
7200 receiving the multicast on a NPE-G1, sending on the same NPE-G1 to a
7600, arriving on a ws6748 with DFC3, going to a OC12 to Rio, arriving on a
7600 on a OC12, uplinking to a 3560 via a Sup32, 3560 going
On Monday, September 12, 2011 05:45:06 PM Nick Hilliard wrote:
I would be interested to hear your opinion on how tcp over multicast would
work.
Of course, straight TCP won't work over multicast. There are other protocols
which will meet the suggestions of RFC 3048.
But I agree with your
On Monday, September 12, 2011 07:47:14 PM Persio Pucci wrote:
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
Hi folks,
I am having some problems trying to figure out what could be causing UDP
packets get out-of-sequence on some multicast streams (market data) between
Sao Paulo and New York.
There is no part of this path with parallel, load-balanced connections,
which could be a obvious cause. What else
How are you certain that there are no load balanced paths along the way?
Even if there are none shown in your traceroutes there may still be routes in
your providers network that are doing this (MPLS with propogate-ttl disabled)
that would mean you wouldn't see it happening.
Just my 2 cents...
David,
it's a POS OC12 SDH circuit we have, so unless the carrier is doing
something funny SDH-wise, it's a sigle path... :/
On Mon, Sep 12, 2011 at 10:24 AM, David Rothera david.roth...@gmail.comwrote:
How are you certain that there are no load balanced paths along the way?
Even if there
kk, just wanted to check :)
Sent from my iPad
On 12 Sep 2011, at 14:28, Persio Pucci wrote:
David,
it's a POS OC12 SDH circuit we have, so unless the carrier is doing something
funny SDH-wise, it's a sigle path... :/
On Mon, Sep 12, 2011 at 10:24 AM, David Rothera
On Sep 12, 2011, at 6:38 PM, Persio Pucci wrote:
Any ideas or tips?
Is this across the Internet, or a WAN/VPN?
Is there any intermediate device other than a router?
---
Roland Dobbins rdobb...@arbor.net //
Chris,
there's no QoS anywhere on the path to avoid this kind of problems. As for
the sequence being received right int the first place, we do have servers
monitoring the channels in Sao Paulo and NY and we see gaps (out-of-sequence
packets) only in NY.
Giving a quick look at live capture I see
Roland,
it is a router-sdh-atlantic ocean-sdh-router circuit :)
On Mon, Sep 12, 2011 at 10:41 AM, Dobbins, Roland rdobb...@arbor.netwrote:
On Sep 12, 2011, at 6:38 PM, Persio Pucci wrote:
Any ideas or tips?
Is this across the Internet, or a WAN/VPN?
Is there any intermediate device
There is no part of this path with parallel, load-balanced connections, which
could be a
obvious cause. What else could I check? The packets do arrive, so they are
not being
dropped on the way, but they arrive out of sequence, being useless to the
application.
I've seen UDP packets (also
Might be something funny going on with APS, and if you are only seeing it at
the NY end, then I would start at the NY landing station sonet equipment.
Reason is, the NY Sonet equipment may be passing both data streams (working
+ protect) on occasion.
I am making assumptions here that the local
On Monday, September 12, 2011 07:38:38 AM Persio Pucci wrote:
I am having some problems trying to figure out what could be causing UDP
packets get out-of-sequence on some multicast streams (market data) between
Sao Paulo and New York.
You may know all of what I'm going to say below... but just
On Sep 13, 2011, at 3:08 AM, Lamar Owen wrote:
If the application relies on 100% in-order delivery, it shouldn't be using
straight UDP.
Or, it should have reasonable error-correction/tolerance for out-of-order
packets.
;
...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland
Sent: Monday, September 12, 2011 4:20 PM
To: Cisco NSP
Subject: Re: [c-nsp] Troubleshoot UDP out-of-sequence
On Sep 13, 2011, at 3:08 AM, Lamar Owen wrote:
If the application relies on 100
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
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
-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland
Sent: Monday, September 12, 2011 3:20 PM
To: Cisco NSP
Subject: Re: [c-nsp] Troubleshoot UDP out-of-sequence
On Sep 13, 2011, at 3:08 AM, Lamar Owen wrote:
If the application relies on 100% in-order delivery, it shouldn't be using
straight
Persio Pucci wrote:
Hi folks,
I am having some problems trying to figure out what could be causing UDP
packets get out-of-sequence on some multicast streams (market data) between
Sao Paulo and New York.
Are there any Juniper M160's in the path of the packets? Those were
notorious for
20 matches
Mail list logo
