Subject: Re: SCTP Mulithoming Communication PATHS Query

From: Xiangsong Cui <[email-masked]>
Date: Fri, 16 Apr 2010 17:28:41 +0800

Hi Samba,

I removed ietf list from the mail.
please see my comments inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Sambasiva Rao Manchili" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: "Antonio Gambin" <[email-masked]>; "Markus Locher" <[email-masked]>
Sent: Friday, April 16, 2010 5:03 PM
Subject: RE: SCTP Mulithoming Communication PATHS Query

Hallo Xiangsong,
Thanks a lot for the detailed mail.
>> It seems there is firewall between host-X and host-Y, so the cross path packets can not reach the destination?
There is no fire wall but two separate routers each carrying a path and these routers are not connected as well.

[Xiangsong] do you mean the following network?
                 (px) --- (Router) --- (py)
A: host-X                                         host-Y
                 (ax) --- (Router) --- (ay)

>>1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X when  it exceeds max retranmission in same path(cross) 
>>consecutively and
>> If the path of IPax -- IPay is OK, this should not happen, this is the key point.
Yes, because of this KEY point it is marked NETWROK UP in next second and again after a while(a minute or few minutes inless than 3)
that is marked NETWORK DOWN

[Xiangsong]
Network Up is right, but in this situation both hosts should not go to network down.

>>Do you see the HB message (or DATA chunk) in the parallel path? or host-X only sends HB in the cross path?
HB message and DATA chuck are seen in parallel path. Host-X is sending in parallel paths and  sending also in cross intermittently. 
During this intermittent cross path communication once it reaches maximum number CONSECUTIVELY then immediately it marks DOWN and 
next second or milliseconds it marks NETWORK UP again as there is also parallel communication path attempted and succeeded.

[Xiangsong]
Do you see SACK chunk or HBAck in the parallel path?
And, I want to identify the three instances,
the path, e.g. the path of IPpx--IPpy,
the destination, e.g. the destination of IPpy, and
the association, e.g. the association between host-X and host-Y.
could you tell me exactly which instance is down? the path? the destination? or the association?
or maybe which one is down firstly, and later lead another instance to be down?

I am asking the following question though it might not be very right to ask you, but would like to hear from your experience.
Given this situation, as I a responsible person for Host-X stack, what can be optimal values for the following parameters.
1. RTO Initial
2. Path MAX Retransmissions
3. Assoc MAX Retransmissions
4. MAX Init Retransmissions.

[Xiangsong]
I guess this is not a parameter trouble, your configuration in you previous mail sounds OK

-- Xiangsong

I do not want to stop the cross communication from Host-X(as I do not have full freedom to do that at the moment)
I can not definetly leave Host-X with values mentioned in my mail, as I get events NET DOWN for every few minutes and NET UP after 
few milliseconds subsequently.  With your answer, I will be in a position to convince the customer with your vast knowledge and 
expertise.

Best Regards
Samba.

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]]
Sent: Friday, 16. April, 2010 09:25
To: Sambasiva Rao Manchili; [email-masked]
Cc: Antonio Gambin; Markus Locher
Subject: Re: SCTP Mulithoming Communication PATHS Query

Hi Samba,

It seems there is firewall between host-X and host-Y, so the cross path packets can not reach the destination?

In my understanding, some aspects may impact the result.

As far as I know, different vendors maybe provide different implementation.

some provide parallel path, like

                 (px) ----- (py)
A: host-X                           host-Y
                 (ax) ----- (ay)

while some provide both parallel and cross path, like

                  (px) ------ (py)
B:  host-X             X            host-Y
                  (ax) ------ (ay)

So, if host-Y takes implementation A, I guess the result would not change even you re-configure the network, because host-Y would 
not return HBAck in the cross path when it receives the HB message (it doesn't think the cross path is SCTP PATH), I did ever see 
such device.

But, the more important point is host-X, it looks very strange.

1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X when  it exceeds max retranmission in same path(cross) 
consecutively and

If the path of IPax -- IPay is OK, this should not happen, this is the key point.
Host-X would also send HB to IPpy by the source address IPpx, and send HB to IPay by the source address IPax, and the corresponding 
HBAck would be returned by host-Y, so num of retransmission would be reset to 0. In the viewpoint of host-X, the right result should
be: parallel paths are both OK and cross paths are both invalid, but the association should be OK.

Do you see the HB message (or DATA chunk) in the parallel path? or host-X only sends HB in the cross path?

By the way, [email-masked] is a better list for this discussion.

Regards
Xiangsong

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. 
If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are 
prohibited from copying, disseminating or otherwise using the email or any attachment.

---

From: Sambasiva Rao Manchili <[email-masked]>
Date: Fri, 16 Apr 2010 11:03:29 +0200

Hallo Xiangsong,

>>1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X when  it exceeds max retranmission in same path(cross) consecutively and

>>Do you see the HB message (or DATA chunk) in the parallel path? or host-X only sends HB in the cross path?
HB message and DATA chuck are seen in parallel path. Host-X is sending in parallel paths and  sending also in cross intermittently. During this intermittent cross path communication once it reaches maximum number CONSECUTIVELY then immediately it marks DOWN and next second or milliseconds it marks NETWORK UP again as there is also parallel communication path attempted and succeeded.

I do not want to stop the cross communication from Host-X(as I do not have full freedom to do that at the moment)
I can not definetly leave Host-X with values mentioned in my mail, as I get events NET DOWN for every few minutes and NET UP after few milliseconds subsequently.  With your answer, I will be in a position to convince the customer with your vast knowledge and expertise.

Best Regards
Samba.

-----Original Message-----
From: Xiangsong Cui [mailto:[email-masked]]
Sent: Friday, 16. April, 2010 09:25
To: Sambasiva Rao Manchili; [email-masked]
Cc: Antonio Gambin; Markus Locher
Subject: Re: SCTP Mulithoming Communication PATHS Query

Hi Samba,

                 (px) ----- (py)
A: host-X                           host-Y
                 (ax) ----- (ay)

                  (px) ------ (py)
B:  host-X             X            host-Y
                  (ax) ------ (ay)

So, if host-Y takes implementation A, I guess the result would not change even you re-configure the network, because host-Y would not return HBAck in the cross path when it receives the HB message (it doesn't think the cross path is SCTP PATH), I did ever see such device.

1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X when  it exceeds max retranmission in same path(cross) consecutively and

If the path of IPax -- IPay is OK, this should not happen, this is the key point.
Host-X would also send HB to IPpy by the source address IPpx, and send HB to IPay by the source address IPax, and the corresponding HBAck would be returned by host-Y, so num of retransmission would be reset to 0. In the viewpoint of host-X, the right result should
be: parallel paths are both OK and cross paths are both invalid, but the association should be OK.

Regards
Xiangsong

This email and any attachment may contain confidential information which is intended for use only by the addressee(s) named above. If you received this email by mistake, please notify the sender immediately, and delete the email from your system. You are prohibited from copying, disseminating or otherwise using the email or any attachment.