Subject: source-address selection problem

From: JinyangSHI <[email-masked]>
Date: Fri, 15 Nov 2002 21:07:22 +0800

hi, dear all:

the following is a thread in [tsvwg maillist] from Lev:
-----------------------------------------------------------
>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.

>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
-----------------------------------------------------------

The following is from me:

I think it is a problem of source-address selection.

We maybe have two strategies to select a source address for a packet: 
   one is just to look up in the routing table according to the destination; 
   but sometimes the route-table maintained by the OS can't recognize the destination and will thus make some mistakes, so in such cases, we need to select the source address by ourselves, that is, to select the network interface by ourselves.

    I think Lev's problem is under the second strategy: If the destination is 3.2, we will always select 1.2 as the source addesss by ourselves. In such case, even the the IP packet sent via 2.2 interface, the IP source address will still be 1.2.
    As a result, endpoint A go on sending patkets via 2.2 interface, these packet reach endpoint B, B send SACK back to 1.1, and all the SACK can't not reach A, transfering fail. However the HeartBeat and HeartBeat-Ack between 2.2-3.2 can still communicate as normal, the association is always on, but we we can't transfer data from A->B.

But i think if we use the second strategy and select 1.1 as the source address, we should let the packet sent via the same interface.
--------------------
I had done a similar experiment before, based on Linux environment. I take the first strategy
 and just let the OS select the source IP address by itself.

    +------------+           *~~~~~~~~~*            +------------+
    | Endpoint A |          *   Cloud   *           | Endpoint B |
    |  10.4.0.1  +---------+ x.x<--+     |          |            |
    |            |         |       |->x.x|----------+ 10.2.0.1   |
    |  10.3.0.1  +---------+ x.x<--+     |          |            |
    |            |          *           *           |            |
    +------------+           *~~~~~~~~~*            +------------+

The following is the ethereal trace:

[01] INIT     chunk from 10.4.0.1 to 10.2.0.1;
[02] INIT-ACK chunk from 10.2.0.1 to 10.4.0.1.

In the INIT chunk, we can find two IPv4 addresses: 10.3.0.1 and 10.4.0.1.
Then send a message :

[03] DATA chunk from 10.4.0.1 to 10.2.0.1, 
[04] SACK chunk from 10.2.0.1 to 10.4.0.1, 

[05] HEARTBEAT     chunk from 10.4.0.1 to 10.2.0.1, 
[06] HEARTBEAT-ACK chunk from 10.2.0.1 to 10.4.0.1, 

[07] HEARTBEAT     chunk from 10.2.0.1 to 10.3.0.1, 
[08] HEARTBEAT-ACK chunk from 10.4.0.1 to 10.2.0.1.

[09] HEARTBEAT     chunk from 10.2.0.1 to 10.4.0.1, 
[10] HEARTBEAT-ACK chunk from 10.4.0.1 to 10.2.0.1.

The association is established between A and B, and data is passing through. We can find that the active interface on endpoint A now is eth1(10.4.0.1). Then we disable the currently active interface (eth 1: 10.4.0.1 ):

[11] DATA chunk from 10.3.0.1 to 10.2.0.1, 
[12] SACK chunk from 10.2.0.1 to 10.3.0.1, 

We look into the HEARTBEAT :

[13] HEARTBEAT chunk from 10.3.0.1 to 10.2.0.1, 
[14] HEARTBEAT ACK chunk from 10.2.0.1 to 10.3.0.1, 
[15] HEARTBEAT chunk from 10.2.0.1 to 10.4.0.1, 
[16] No HEARTBEAT ACK
[17] HEARTBEAT chunk from 10.2.0.1 to 10.3.0.1, 
[18] HEARTBEAT ACK chunk from 10.3.0.1 to 10.2.0.1.

The association is still established between A and B, and data is passing through. We can find that the active interface on endpoint A now is eth0(10.3.0.1).

--------------------
From the ethereal trace, we can have two conclusions:

    One, From [11], we can see that Lev's problem never happen, because we use fisrt strategy.
    Two, From [08]. When endponit A receive HEARTBEAT[07] from 10.2.0.1 to 10.3.0.1, then it HEARTBEAT ACK[08] back to 10.0.2.1, and with source address 10.4.0.1 selected by route table, other than 10.3.0.1. I think this isn't reasonable, in other experiments we have find it will result in mistakes, therefore in some case so we need the second strategy, that is, to selece source address by ourselves.

Randy had mentioned source-address-selection in their book, but he assumes that we will always know the route table, i think it seems that in most time we may not alawys konw it.

So we try to study two problems: in whick case we need to use the second strategy, and how we select the source address? Especially we maybe nerver know how the OS maintains the route table.

I am not sure if i express myself clearly, and wish for more guidance and discussion -:)

Best regards
Yang
11/15

---------------------------------
Jinyang SHI
Mail:  [email-masked]

Office:(86-10) 65392828-2759
Nokia(China) R&D Center

Lab:   (86-10) 62283757
Broadband Network Research Center,
National Lab of Switching Tech. and Telecom Networks,
Beijing University of Posts and Telecommunications(BUPT), P.R.China