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.
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
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 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.
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:Xiangsong(_dot_)Cui(_at_)huawei(_dot_)com]
Sent: Friday, 16. April, 2010 09:25
To: Sambasiva Rao Manchili; ietf(_at_)ietf(_dot_)org
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, tsvwg(_at_)ietf(_dot_)org 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf