Subject: Re: SCTP Mulithoming Communication PATHS Query

From: Randall Stewart <[email-masked]>
Date: Fri, 4 Jun 2010 18:20:19 -0700

On Apr 15, 2010, at 3:30 AM, Sambasiva Rao Manchili wrote:

>
> Hallo,
>
> I  have a query related to SCT Mulithoming communication paths.
> Host-X: (IPpx  IPax): Multihomed Association  with Host-Y (IPpy   
> IPay).
>
> Host-X  SCTP Client is running with SCTP stack provided by Vendor X
> Host-Y  SCTP Server is running with SCTP stack provided by Vendor Y.
>
> Notation.
> IPpx  means IP Address of Primary  path on Host-X
> IPax  means IP Address of Alternate path on Host-X
>
> IPpy  means IP Address of Primary path on Host-Y
> IPpy  means IP Address of Primary path on Host-Y
>
> Host-X is Communicating as follows :-
> -------------------------------------------------------
>
> Primary IP  to Primary IP
> Host-X(IPpx)--------HBEAT---------->Host-Y(IPpy)
> Host-X(IPpx)<-------HBEAT-ACK------Host-Y(IPpy)
>
> Alternate IP to Alternate IP
> Host-X(IPax)--------HBEAT---------->Host-Y(IPay)
> Host-X(IPax)<-------HBEAT-ACK------Host-Y(IPay)
>
> /*
>  * Host-X installed in Customer network.
>  * Customer Network not configured/ not capable to deliver to  
> destination
>  * in the following two paths. I do not know if they have special  
> requirement
>  * to configure their network only primary talks to primary and  
> alternate talks
>  * to alternate, but I see disadvantage in their setup.
>  * Host-X  keeps on trying to reach every Destination received in the
>  * INIT_ACK message from Host-Y
>  *
>  */
> Primary to Alternate Address
> Host-X(IPpx)--------HBEAT---------->Host-Y(IPay) (DOES N0T REACH IPay)
> Host-X(IPax)--------HBEAT---------->Host-Y(IPpy) (DOES NOT REACH IPpy)

Hmm.. Most implementations are satisfied with reaching the destination..
i.e. when you do Primary IP  to Primary IP or Alternate IP to  
Alternate IP
this should be all that is needed. In fact at all previous inter-ops the
networks were configured as you say here. You CANNOT send a packet from
the primary network and have it cross to the secondary. They were always
isolated. In fact this is often done to have "separate and diverse"  
networks
so you have no single point of failure. Placing a router where both
networks plugged in to i.e.

IPpx-------------\    +--------+    /--------- IPpy
                   \---|        |---/
                   /---|   R1   |---\
IPax-------------/    +--------+    \---------- IPay

Though it would make it so you could cross between IPpx - IPay
and IPax - IPpy.. also introduces a single point of failure.

The implementation should really work in this situation above. As I
said its how ALL of the SCTP interop's were setup. We did have issues
at times with folks setting up their routing tables though. They had
to be sure to set in the routes correctly. In fact this is how most
implementations I am aware of decide on the source address to put in
a packet. They basically follow the router out of the box to determine
the interface that the packet will be emitted on and then use the IP
address of that interface. That helps so that you won't have ingress
filtering cause you grief. As long as you were not using a
default route and had two network routes setup to keep IPp traffic
on the correct network and vice versus there should be no problem with
this scenario... of course it could be one of the implementations is
buggy... not all implementations have been at interops.. most but there
are a few that have never made it to one.. I would most suspect that
you are probably dealing with such a implementation ;-0

>
>
> Now Host-X was forced to configured Path Max Retransmissions and Max  
> Init Retransmissions to value of 5, while RTO Initial and RTO MAX  
> value is set to 1 second.
> This results

5 is actually the default value in the RFC.. but it should be settable  
by socket options :-)

> 1. to mark the destination endpoint IPay as NETWORK DOWN on Host-X  
> when  it exceeds max retranmission in same path(cross) consecutively  
> and
>
> 2. then sends INIT from IPpx to IPpy and also IPpx to IPay and as  
> soon as it gets  the response from any destination(in customer  
> nework only from IPpy) it is marked as NETWORK UP,
>
> 3. but soon or later we receive again NETWORK DOWN and same repeats  
> from step 1.
>
>
> Now the query is,
> Is it right to tell custome Network to re-configure their network to  
> allow
> cross communication ?
>
> OR
>
> Is it MUST to change the Host-X stack to stop communicating Cross
> i.e., IPpx trying to reach IPay.

Well I would think Host-X's stack is rather broken. It really should
not be trying to cross communicate IMO.

>
> Advantage that I see from Host-X Stack :
> I also see an advantage with Host-X tranport addresses IPs trying to  
> reach every destination
> of the peer.

When you say every destination.. you are really saying every  
destination with every
source address. Which is not the same as every destination. If you CAN  
reach
IPpx from IPpy .. then IPpx IS reachable. It is often the case that  
address
filtering by an ISP would provide this same behavior. A path in SCTP  
is NOT
the combination of a source and destination address... but ONLY a  
destination address.
Thus if the peer has two addresses and I have two addresses.. you  
really each should
have two paths. It is recommended to switch source addresses in some  
cases where you
are not communicating but they really should NOT be considered  
separate paths.

Think of this same case you illustrate with two internet providers at  
each end. And they
both do address filtering. If I emit a packet on IPp with a source  
address of Ipa and a
destination of IPp the packet will be dropped... Its not quite the  
same scenario as
you are illustrating, but if the host was considering src IPp to dest  
IPa a path then
you would see similar bouncing "paths"..

I really consider this the case that the stack in question is  
broken... SCTP was never intended
to include the source address in the path distinction...

There is nothing wrong with allowing cross traffic.. you are correct  
in that
it CAN in some cases improve fault tolerance... (as long as there are  
more
than one router involved)... but the spec was never designed to consider
the source address as part of the path .. i.e. its only the  
destination address.
R

> The advantage is If the path between the  Host-Y(IPpy)  and its next  
> hop is broken and
> If the path between Host-X(IPax) and its next hop is broken still  
> Multihoming makes real sense and
> could cope up with such breakdown in network while Host- 
> X(IPpx)------->Host-Y(IPay)
>
> If I overlook any other disadvantage of Host-X stack, please correct  
> me.
>
> Looking forward for your suggestion from your expert knowledge. If  
> something not clear please feel to ask me.
> Thanks in advance.
>
> Thanks,
> samba.
>
>
>
> Sambasiva Rao Manchili
> Software Development Engineer
> ________________________________
>
> NEXUS TELECOM AG
> Network and Service Investigation
> Muertschenstrasse 25
> P.O. Box 1413
> CH-8048 Zurich
> Switzerland
>
> Direct/mobile: +41 78 750 6808
> Main: +41 44 355 6611
> Email: [email-masked]
> Website: www.nexustelecom.com
>
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

------------------------------
Randall Stewart
803-317-4952 (cell)