tinc - Aug 2006 - looking for a tool to tunnel ethernet reliable on internet.

Dear reader, im looking for a tool to tunnel ethernet reliable on
internet.
I have a set of devices do not themself have retransmission build in,
the rely on a "wired" LAN.
The all talk to a central host on a MAC to MAC basis.
I want to bring the devices far away from the Host and link them up via
internet, but packet drop on internet is my problem!

The tinc is almost perfect for my purpose, but as I understand it the
"Data" channel is build on UDP and is not reliable.
The Meta-protocol is build on TCP and is reliable.

Is there any way I can use the tinc in a reliable hub mode ?

The performence needs are very small, 64kbit/sec max delay 4 seconds.

Best regards

Henrik T Jensen

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://brouwer.uvt.nl/pipermail/tinc/attachments/20060803/aa2aaeb2/attachment.html

On Thu, Aug 03, 2006 at 03:50:11PM +0200, Henrik T. Jensen (HTJ)
wrote:
>    Dear reader, im looking for a tool to tunnel ethernet reliable on
>    internet.
>    I have a set of devices do not themself have retransmission build in,
>    the rely on a "wired" LAN.
... which is, of course, also unreliable (i.e. ethernet does not guarantee
packet delivery)
>    The all talk to a central host on a MAC to MAC basis.
>    I want to bring the devices far away from the Host and link them up
>    via internet, but packet drop on internet is my problem!
If you add retransmission at the link layer, you have to be extremely
careful. What you end up with is packet loss replaced by some packets
suffering long delays.

TCP, in particular, behaves extremely badly under this situation, because it
relies on seeing packet loss for congestion control. The loss of the
congestion control mechanism can result in catastrophic failure under load.
>    The performence needs are very small, 64kbit/sec max delay 4 seconds.
And what about packet reordering? Is it OK to deliver packet 1 2 3 5 6 7 4 ?

If not, then you will get 1 2 3 ...delay... 4 5 6 7, where 'delay' is
the
time taken to realise that packet 4 has not been transmitted, and either to
request retransmission explicitly, or for the sender to realise that the
acknowledgement is missing.

A 1512-byte ethernet frame will take 200ms to transmit at that speed.
However your retransmission algorithm will need to be very good to ensure
that there is no more than a 4 second gap even in the event of several
packets being lost.

If you *really* still want bridging over an error-corrected link, I think
OpenVPN does bridging over TCP. But with the loss of one or two packets in
sequence, the delay may become too large for you, and as I say, if you end
up running TCP over TCP you can expect severe problems.

Regards,

Brian.