[zeromq-dev] Preferred Transport to Handle Lossy Networks?

[Peter Witkowski]

All,

Thanks for the help thus far.  While I'm aware that I can probably just use
a transport outside of 0MQ, I really like the ability to abstract away my
messages and not have to worry about things like out of order arrival and
having to chop up my messages into smaller, more digestible pieces.

Here are my near-goal requirements restated:
1.  I have N nodes that need to forward data to a single processing node
(many-to-one, but more than likely N one-to-one connections).  The physical
layer is an airFiber wireless link that may cause packet loss (currently
testing to see how good/bad it is).
2.  I'm OK with data being resent (actually reliability is probably a good
thing) and latency is a lesser concern (unless it becomes on the order of
several seconds).  What I want to avoid is TCP-like congestion control
(i.e., "if data gets dropped, let's resend it slower").

Is there anything out of the box in 0MQ to support this?  I'm hoping to
have something turn-key, because my other option is to just do what I've
done in the past and use UDP sockets and push a bunch of requirements (out
of order packets, resending if things get dropped, stamping each packet
with a sequence number, carving my messages down into smaller chunks so I
can send it over UDP, etc.) up to the application layer.  I don't want to
do this for two reasons.  First, I've done this before (there is nothing
more scary in computing than when someone defends a design with "it's what
we've always done") and second it's going to be a bit of a pain (see list
of requirements).

Thanks again for the help.  This thread has actually pointed me at some
very promising technologies I didn't yet know existed.

On Tue, Jun 2, 2015 at 6:01 PM, Brian Adamson <brian.adamson at nrl.navy.mil>
wrote:

> Another option here is the NORM protocol.  One thing to note is NORM in
> ZMQ uses its default TCP-Friendly congestion control mechanism by default.
> For lossy wireless links, this particular congestion control approach uses
> packet loss as a congestion indicator just like TCP and thus has similar
> issues.
>
> However, NORM _can_ be set to operate at a fixed rate and also has options
> for an ECN-based mode of congestion control that uses ECN to detect
> congestion instead of packet loss (for the most part).  It also can be
> configured to provide a simple loss-tolerant form of congestion control
> similar to what UDT offers where isolated packet loss is discounted as a
> congestion indications.  With one of these alternative congestion control
> mechanisms, NORM can provide good performance in lossy wireless
> environments.  I think it would be possible to expose some of these
> additional options somehow, but I haven’t had a tremendous amount of time
> recently to investigate this further.  Like UDT, you could use NORM (it has
> its own API) separate from ZMQ if you like.
>
> cheers,
>
> Brian
>
>
> On Jun 1, 2015, at 3:47 PM, Peter Krey <krey at ripple.com> wrote:
>
> In this context of 1 to 1 transfer then yes I agree that UDT protocol will
> best meet your needs.
> http://udt.sourceforge.net/
>
>
> On Mon, Jun 1, 2015 at 12:43 PM, Steven McCoy <steven.mccoy at miru.hk>
> wrote:
>
>> On 1 June 2015 at 12:33, Peter Krey <krey at ripple.com> wrote:
>>
>>> Yes use the PGM or EPGM transport. If you want to use an additional
>>> layer at the application level, you can implement your own resend logic
>>> with message sequence numbers if your network is truely massively losing
>>> messages.
>>>
>>>
>> I think on wireless PGM is not a great idea unless you can implement a
>> congestion control method that works, with tweaks for radio interference
>> patterns.  PGM is 1-to-many, for 1-to-1 there are a plethora of options, my
>> first choice excepted it not being implemented in 0MQ would be QUIC from
>> Google, for long links it would be UDT.  For real lossy environments you
>> may need UDP-Lite and possibly a one-way broadcast channel.
>>
>> I'm the developer of the PGM implementation, the project is currently on
>> hiatus until I have a new use case for it.  Presently I only have need to
>> 1-to-1 channels.
>>
>> --
>> Steve-o
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
Peter Witkowski
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150603/45a3e5c6/attachment.htm>