Subject: Re:RE: [tsvwg] multihoming with asymmetric endpoints

From: JinyangSHI <[email-masked]>
Date: Fri, 15 Nov 2002 20:33:39 +0800

hi,

>> 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<--+     |          |            |
>>     |            |          *           *           |            |
>>     +------------+           *~~~~~~~~~*            +------------+

>	This way everything goes alright. 
>	I would say that if you bind to INADDR_ANY the source IP
>address should be set to that of the physical source used. If you set
>the source IP address by yourself, you should take care with what you
>are doing... :-/

I think this is a problem of source-addreee selection.

We maybe have two strategies to select a source address for a patket: 
   First 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, then B send SACK back to 1.1, and all the SACK can't reach A, so 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 receives HEARTBEAT[07] from 10.2.0.1 to 10.3.0.1, then it sends 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 lead to mistakes, therefore in some case 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, 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 Laboratory of Switching Technology and Telecommunication Networks,
Beijing University of Posts and Telecommunications(BUPT), P.R.China
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 19 Nov 2002 08:24:46 -0600

A couple of comments to all the comments :->

1) I think that the draft also mentions that you should always
   use the IP address of the interface for which the packet is
   emitted upon (if possible)... or something like that. Now the
   if possible is in reference to the local endpoints binding... in
   your example if both 1.2 and 2.2 are bound.. then when you start
   sending packets via 2.1 you should change your source address to
   match the interface aka the source should be 2.2.

2) Lets say for some reason you do NOT do this.. which you should..
   A GOOD implementation will still stay up and tranfer data.. although
   at a deminished throughput rate... the reason being some other subtle
   wording in RFC2960... Yes you are to reply to the source address..
   however the peer (at 3.2) when it sees duplicate packets should
   assume the SACK was lost and should thus use the alternate address
   aka 2-1. I know our implementation uses the fact of duplicates to
   select an alternate to the source address of the packet to send
   the SACK to... There is some wording in the RFC that hints at this
   I am to short on cycles to dig through and find it... but when
   things are going wrong in general alternates should come in to
   play.

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)