Menu
▾
▴
Re: [Lksctp-developers] Query regarding Primary destination IP
|
From: Vlad Y. <vla...@hp...> - 2010-04-21 13:22:55
|
Hi Wei Wei Yongjun wrote: > Sorry to reply on top. > > I also saw similar problem when I do multi-homed test. > If COOKIE-ECHO is retransmit from the alter address, the > COOKIE-ACK will reply to the old primary IP. Like this: > > Endpoint A Endpoint B > > INIT -------> > (On Address1) > <------- INIT-ACK > (On Address1) > COOKIE-ECHO > (On Address1) ---(lost)---> > COOKIE-ECHO retransmit > (On Address2) ------------> > > <------------ COOKIE-ACK > (still reply to Address1) > > If Address1 can not be arrived from endpoint B any more, > the ASOC can not be ESTABed. > > And even if we send COOKIE-ECHO from an address which is > not a port of asoc, the COOKIE-ACK can still reply to > address1. In other word, endpoint B does not check the > source address of COOKIE-ECHO, only check address in the > cookie. > > I think we need the check the source address of > COOKIE-ECHO and set the source address as primary > path in endpoint B. But the RFC notice nothing about > this. > General notice in the spec is that responses should be sent back to the source. That applies as often as possible. When we generate a cookie-ack, we try to send it on the same transport that cookie-echo came in on. It should work in both cases, so there is probabably something wrong. According to source, when we process a cookie-echo for a new association, we don't have incoming transport yet. The source of the packet is added first and becomes primary/active, so responses will go there. (correct behavior) When we already have an association, we'll get the transport that received the packet filled in. That will get assigned to the cookie-ack chunk. If that transport is by any chance unconfirmed, then cookie-ack will be sent back on the active path. That's probably what we are seeing. Addition potential issue I see in the duplicate cookie code is that cookie-ack is sent from the new, temporary association, but could potentially use the transport from the existing association. Not sure what issues this would cause, but it feels wrong. -vlad >> Padmalochan Moharana wrote: >> >>> Hi, >>> >>> I have a query regarding sctp multihoming behavior. >>> >>> As per the rfc4969 server should treat the first IP in the INIT message >>> as the client’s Primary IP. So Server should send the data to that IP >>> after restart of association.But my application sends data to the >>> primary IP that selected at the time of initialization of association. >>> >> Association restart is completely different from a newly formed association >> and doesn't change previously known primary destination. >> >> When talking about primary vs secondary, we are talking about destinations >> not source addresses. >> >> >>> For example during initialization of association the primary IP of peer >>> was 23.1.1.37 and the secondary IP was 23.1.1.38. >>> >> OK. So the client sent the INIT from .37 and included .38 as an additional >> address. >> >> >>> Suppose after some >>> time peer primary IP goes down So peer restarted the association by >>> sending INIT with 23.1.1.38 as the primary IP. >>> >> Why did the peer restart because of failed primary. It should switch to >> using the secondary source if it's available. >> >> >>> So after >>> re-initialization of association, now application should use 23.1.1.38 >>> as the primary destination IP. But my application still sends DATA to >>> 23.1.1.37. >>> >> If the association simply restarted, the primary designation has not changed >> since from the perspective of the receiver of the restart, the primary may >> still be reachable. >> >> >>> My application using OS- 2.6.9-55 and lksctp-1.0.8. >>> >>> >> This is also very old, but this behavior has not changed a whole lot. >> >> -vlad >> >> >>> I have attached the wireshark trace for the same issue. Please have a >>> look and let me know how I can avoid this issue. >>> >>> Regards, >>> >>> Padmalochan >>> >>> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Lksctp-developers mailing list >> Lks...@li... >> https://lists.sourceforge.net/lists/listinfo/lksctp-developers >> >> >> > |