Re: Re: [Sigtran] The requiremnts and 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)