All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Lister Peter Lister <P.Lister@sychron.com>
To: lartc@vger.kernel.org
Subject: [LARTC] Question - duplication of packets for reliability
Date: Thu, 02 Nov 2000 12:48:27 +0000	[thread overview]
Message-ID: <marc-lartc-98373938216885@msgid-missing> (raw)

<PRE>We have offices in the UK and the US, both with DSL connections. Linux
routers at both ends. We frequently get high packet loss (&gt;10%) and
have had occasional ISP router outages. Yes, we can spend more money
on a leased line, but even so, the transatlantic / continental
carriers on the leased line have had routing problems when the DSL has
been OK. TCP traffic becomes very slow with any appreciable packet
loss - terminal traffic is very slow indeed. End-to-end service
providers cost a fortune - and we don't need very high bandwidth. The
speed of light dictates that we'll always have fairly high latency, so
any retransmissions will be noticeable.

So - it occurs to me that we could use multiple cheap DSLs at both
ends from different telcos/ISPs to guarantee that office-office comms
work. My thought is that something like eql (I'll call it &quot;dup&quot;) can
be adapted to duplicate all packets down several links rather than
distributing packets down each link.

             UK              US

         uk-dsl0 ---------  us-dsl0
                 \___  ___/
      /              \/              \
  uk-dup0         ___/\___            us-dup0
      \          /        \          /
         uk-dsl1 ---------  us-dsl1


Every packet into dup0 generates 4 packets out (eth0-eth0, eth0-eth1,
eth1-eth0, eth1-eth1). The exact mechanism isn't the point (I imagine
4 VPNs of some sort, enslaved by dup in the same way as eql) - we just
make multiple packets end up at the destination router somehow.

Q 1: Does mass duplication cause problems to e.g. TCP, which probably
expects a small amount of duplication in the same way that it expects
a small amount of packet loss?

Q 2: Are there any alternative / better (Linux) solutions to provide
this sort of resilience over high latency connections?

Q 3: Has anyone written &quot;dup&quot; ? :-)

-- 
Peter Lister         <A HREF="mailto:P.Lister@sychron.com">P.Lister@sychron.com</A>    PGP (RSA): 0xE4D85541
Sychron Ltd          <A HREF="http://www.sychron.com">http://www.sychron.com</A>  PGP (DSS): 0xBC1D7258
1 Cambridge Terrace  Voice: +44 1865 200211
Oxford OX1 1UR  UK   FAX:   +44 1865 249666




</PRE>

                 reply	other threads:[~2000-11-02 12:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-98373938216885@msgid-missing \
    --to=p.lister@sychron.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.