RE: Re: [Sigtran] The requiremntsand proposalsforM2PA/M3UA/SCTPExtension from China Mobile

Hi,

Won't this association have a serious problem with Heartbeats if you cannot send a Heartbeat Ack to the address the Heartbeat came from?

>From RFC 2960bis
	3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5): 

	An endpoint should send this chunk to its peer endpoint as a response to a 	HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always sent to the source IP 	address of the IP datagram containing the HEARTBEAT chunk to which this ack is 	responding.

We also need to take into account that the source address of duplicate data may NOT be the source address used for the original data if the sending end has changed paths when the data wasn't acked.

If this is a routing problem which has been in place since the association was started then the sender should never send data to an unconfirmed address.  If the Heartbeat mechanism is broken the address will never be confirmed.

Ronnie
---
Ronnie Sellar			Emerson Network Power, Embedded Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:[email protected]	http://www.emersonembeddedcomputing.com
 

> -----Original Message-----
> From: Randall Stewart [mailto:[email protected]] 
> Sent: 28 July 2007 11:42
> To: ³ÂÐñ
> Cc: Michael Tuexen; [email protected]; SIGTRAN; TSWG
> Subject: Re: [Tsvwg] Re: [Sigtran] The requiremntsand 
> proposalsforM2PA/M3UA/SCTPExtension from China Mobile
> 
> Chen:
> 
> I pretty much agree with Brian here..
> 
> Most implementations will follow the steps that Brian lists 
> for source address selection. Yes its completely possible to 
> setup routing tables that will not work... but this is a 
> configuration error.. not a deficency in the protocol.
> 
> As to sacks, I think most all implementations that I know of 
> attempt to switch sacks to an alternate destination when they 
> start seeing duplicate data. I will discuss this item with 
> all the developers going to Kyoto for the SCTP-Interop (in 2 
> weeks)... and I will see if anyone does not do this.. I would 
> be quite surprised to see anyone not using the duplicate data 
> (as Brian mentions below) as an indication to move to an 
> alternate address to send the SACK back to.
> 
> R
> 
> Brian F. G. Bidulock wrote:
> > Chen,
> > 
> > ³ÂÐñ wrote:                                  (Fri, 27 Jul 
> 2007 16:45:12)
> > 
> >>Dear Michael Tuexen,
> >>
> >>	
> >>
> >>>   1. What does "unionize of the primary paths between nodes" mean?
> >>
> >>It means£¬for one multi-homed SCTP endpoint,the primary 
> path£¨source 
> >>IP address=IP1---destination IP=IP2£© shall be the same as 
> the remote
> >>endpoint's ( source IP address=IP2---destination IP=IP1  )   
> >>   
> >>Many venders implement Multi-homing in the following way:
> >>
> >>one multi-homed SCTP endpoint has two local IP 
> addresses(IP1/IP2) and 
> >>two remote IP address(IP3/IP4) within an association.  There's two 
> >>paths within an association:IP1-IP3,and IP2-IP4.not 4 paths.
> > 
> > 
> > That sounds rather foolish.  What I do is as follows:
> > 
> >   When sending to IP3, choose the best route (metric) to IP3.
> >   If no route to IP3 exists, don't send to IP3, send to another
> >     destination for the association.
> >   If a route to IP3 exists, and the source address of the outbound
> >     interface of this route includes a local address for the
> >     association, use that as the source address when using 
> the route.
> >     Otherwise, use the first source address of the association.
> > 
> >   When sending to IP4, choose the best route (metric) to IP4.
> >   If no route to IP4 exists, don't send to IP4, send to another
> >     destination for the association.
> >   If a route to IP4 exists, and the source address of the outbound
> >     interface of this route includes a local address for the
> >     association, use that as the source address when using 
> the route.
> >     Otherwise, use the first source address of the association.
> > 
> > This only results in IP1-IP3 and IP2-IP4 if the only route 
> to IP3 is 
> > from an interface with IP1 and the only route to IP4 is from an 
> > interface with IP2.
> > 
> > 
> >>   
> >>For example, endpoint1 has two local IP addresses(IP1/IP2)£¬ and
> >>endpoint2 has two local IP addresses(IP3/IP4).
> >>
> >>if two endpoints' primary path isn't the same,that is endpoint1 use
> >>IP1-IP3 as the primary path, use IP2-IP4 as the second path;
> >>endpoint2 use IP3-IP2 as the primary path, use IP4-IP1 as 
> the second 
> >>path.
> >>
> >>These two endpoints can't  send data to each other successfully.  
> > 
> > 
> > Yes, it is possible to set up your routing tables on two 
> host so that 
> > the cannot communicate.  This is even possible with TCP.
> > 
> > If the problem is not merely routing table, I suggest you choose 
> > another vendor or work with your existing vendor to correct the 
> > deficiencies in their implementation.
> > 
> > 
> >>        
> >>
> >>
> >>>    2. Not sure about the SACK issue: You are currently allowed to
> >>>   send the SACK back to an addresses different from the source
> >>>   address of the corresponding DATA chunk. As far as I know
> >>>   it is only a SHOULD describing that you send the SACK back
> >>>   to the source address of the DATA chunk.
> >>
> >>You are right,it is only a SHOULD describing that you send the SACK 
> >>back to the source address of the DATA chunk in RFC2960.  
> That's why 
> >>we get in trouble in multi-homing situation.  If the  path to the 
> >>source address of the DATA chunk is unreachable£¬the sack 
> can't send 
> >>to the remote endpoint for ever although the other path is 
> >>available.Soon the other path will be failure.
> > 
> > 
> > Well, no, not in the reasonable implementation.  When SACKs 
> are being 
> > sent to a destination and are not reaching the peer endpoint, a 
> > retransmission timeout will result in duplicate TSNs being 
> sent.  The 
> > peer receiving duplicate TSNs should realized that their SACKs are 
> > likely being sent into a black hole and begin sending SACKs to a 
> > different destination.  This is already in RFC 2960:
> > 
> > 6.4 Multi-homed SCTP Endpoints
> > 
> >    ...
> > 
> >    When a receiver of a duplicate DATA chunk sends a SACK 
> to a multi-
> >    homed endpoint it MAY be beneficial to vary the 
> destination address
> >    and not use the source address of the DATA chunk.  The 
> reason being
> >    that receiving a duplicate from a multi-homed endpoint 
> might indicate
> >    that the return path (as specified in the source address 
> of the DATA
> >    chunk) for the SACK is broken.
> > 
> >    ...
> > 
> > If your current vendor does not implement this, I suggest that you 
> > request them to do so.
> > 
> > --brian
> > 
> 
> 
> --
> Randall Stewart
> 803-345-0369 <or> 815-342-5222(cell)
> 
> 
>