All of lore.kernel.org
 help / color / mirror / Atom feed
From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Solved: Using more than 1 Internet Line
Date: Tue, 04 Dec 2001 16:13:20 +0000	[thread overview]
Message-ID: <marc-lartc-100748228723503@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100742079800981@msgid-missing>

 ...
 > > dead. This is *very* cool on UDP, and will make UDP failover to another
 > > route fully transparent.  However, it will not fix stateful protocols in
 > > which the server on the other side keeps state on the IP address it was
 > > talking to, such as SSH.

Sending packets with the same source address out another link only 
helps UDP if it's not necessary to get replies, in which case I
wouldn't call it a "connection".  If you didn't need the replies then
you could do the same thing for TCP.  

Note that this trick only works at all if your ISPs are not doing the 
ingress filtering they should - a safe assumption for now, but I hope
not in the future.

The problem is that you normally don't have any control over the
routing between two places.  Even though your ISPs will let you send
out packets with the source addresses belonging to each other, the
replies will be routed to the one that "should" have sent the packets,
and if that one is down you can't get the replies.

This problem could be fixed by extending TCP (and of course, changing
the kernel) to support multiple IP addresses.  I suggest a new option
that says "here's another IP address for me" (or perhaps, here's an
alternative IP/port).  The kernel then has to merge these two input
streams.  On the output side (when you send to someone who has told
you about alternative addresses) I can think of several ways to
control which address you send to.  I suppose the application should
have some way to influence that, but as a first stab, I suggest that
whenever tcp has to resend a packet, it should move to the next
address.

Anyone interested in trying to implement it?  Put it on your queue and
post to the list if you ever get to it.  Also please post to the list
any bugs (and fixes) you see in the proposal.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

  parent reply	other threads:[~2001-12-04 16:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-02 19:24 [LARTC] Solved: Using more than 1 Internet Line Christoph Simon
2001-12-02 19:41 ` Christoph Simon
2001-12-03 20:22 ` Whit Blauvelt
2001-12-03 20:45 ` Christoph Simon
2001-12-03 21:43 ` Julian Anastasov
2001-12-03 22:04 ` Arthur van Leeuwen
2001-12-03 22:19 ` Christoph Simon
2001-12-03 22:33 ` Whit Blauvelt
2001-12-03 22:44 ` Julian Anastasov
2001-12-04  8:52 ` Arthur van Leeuwen
2001-12-04 10:57 ` Julian Anastasov
2001-12-04 11:05 ` Christoph Simon
2001-12-04 16:13 ` Don Cohen [this message]
2001-12-04 16:20 ` Arthur van Leeuwen
2001-12-04 16:56 ` Don Cohen

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-100748228723503@msgid-missing \
    --to=don-lartc@isis.cs3-inc.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.