Subject: [tsvwg] multihoming with asymmetric endpoints

From: [email-masked]
Date: Thu, 14 Nov 2002 20:47:09 +0200

Hello Lode,

I have to find a solution of the problem with multihoming.

The case is referenced in draft-coene-sctp-multihome-03.txt. Our
configuration is as shown on Figure 2.1.3.

    +------------+           *~~~~~~~~~*            +------------+
    | Endpoint A |          *   Cloud   *           | Endpoint B |
    |      1.2   +---------+ 1.1<--+     |          |            |
    |            |         |       |->3.1|----------+ 3.2        |
    |      2.2   +---------+ 2.1<--+     |          |            |
    |            |          *           *           |            |
    +------------+           *~~~~~~~~~*            +------------+

We are unable currently to apply another IP address to the Endpoint B.
Endpoint A may only choose interface based on destination IP.

About such case section 2.1 said:
    "In IP implementations the outgoing interface of multihomed hosts is
    often determined by the destination IP address. The mapping is done
    by a lookup in a routing table maintained by the operating
    system. Therefore the outgoing interface is not determined by SCTP.
    Using such implementations, it should be noted that a multihomed
    host cannot make use of the multiple local IP addresses if the peer
    is singlehomed. The multihomed host has only one path and will
    normally use only one of its interfaces to send the SCTP datagrams
    to the peer. If this physical path fails, the IP routing table in
    the multihome host has to be changed. This problem is out of scope
    for SCTP."

From other side the RFC2960 said:
   "An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
   etc.) to the same destination transport address from which it
   received the DATA or control chunk to which it is replying".

The problem is following:
The Endpoint A sends all the packages with 1.2 as IP source. If 1.2-1.1
broken it uses
2.2-2.1. (OS changes its routing table). Such behavior required in the
draft.
The Endpoint B verifies two paths and defines that path 3.2-1.2 failed. It
starts to send data using 3.2-2.2. But it still must response on all
HEARTBEAT and DATA chunks to the IP from arrived packets, i.e 1.2. Those
packages will not pass to the Endpoint A without special arrangement in the
network.
I do not think that such special arrangement are always possible. Or if
they possible why to have the multihoming?
Or the conclusion is the singlehomed host do not allow to use multihoming
at all?

Best regards,
Lev

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Andreas Jungmaier <[email-masked]>
Date: Fri, 15 Nov 2002 17:00:17 +0100

Hello Lev, 

please find my comment below:

On Thursday 14 November 2002 19:47, [email-masked] wrote:

- ----------------- snip -------------------------
>     |
>     |
>     |

Well, I think that within the scope of the protocol that is perfectly
okay (if I understand your question here correctly). 
Hearbeat ACKs (from 3.2 <-> 1.2) should not arrive (!), and if the 
SACKs cannot be returned to the 1.2 source address, then the left 
peer will timeout and notice the path failure faster.
This will then trigger retransmission of all TSNs the SACKs of 
which were lost when 1.2 <-> 1.1 broke. 
Retransmission will be done via 2.2 <-> 2.1 <-> 3.1 <-> 3.2 if 
routing is configured correctly (i.e. 2.1 becomes default 
gateway), and all is well !

> they possible why to have the multihoming?

I agree that it is a little complicated, and new. It will take a while,
until all people understand the implications of this asymmetric
multihoming.

Hope this helps, too  !

Regards,
Andreas

- -- 
- ---------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |  Stop sending E-POSTCARDS ! 
Computer Networking Technology Group      |  Send E-MAILS --  Use PGP !
University of Essen                       | 
http://www.exp-math.uni-essen.de/~ajung   |   http://www.gnupg.org
My PGP Key-ID: D3824AC0                   |   http://wwwkeys.pgp.net
- ---------------------------------------------------------------------------
My PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 4AC0 
- ---------------------------------------------------------------------------