Re: regarding 'Association.Max.Retrans'

Padmalochan,

Padmalochan Moharana wrote:                                    (Thu, 09 Nov 2006 00:30:29)
> Hi Brian,
> 
> I have some doubt regarding 'Association.Max.Retrans'
> calculation.
> 
> 1.Suppose end point 'A' have 2 mutihomed source IP and
> end point 'B' have 3 and the 'Path.Max.Retrans' for
> both end is 5. Then what should be the
> 'Association.Max.Retrans' value for the endpoints.

It can take on any value.  What you set it to however, determines your
failover and association abort behavior.

So, in your example, if either end sets Assoc.Max.Retrans to less than
or equal to 5, the association will fail before the non-CMT SCTP will
fail over the primary between destinations.  (CMT SCTP will always
choose the "best" destination.)

If you set Assoc.Max.Retrans to greater than the product of the number
of interfaces and Path.Max.Retrans, then all paths will be considered
failed and it will take additional retransmissions (to some arbitrary
primary) and a potentially long period of time for the association to
fail.  If it is set to some really large number, the association will
effectively never fail, even if it cannot transport any data.

Note that Assoc.Max.Retrans is cleared when a packet is acknowledged.
It is really the number of consecutive retransmission on the
association.  Therefore, the peg counts for some paths could remain at 5
when the path count for one destination becomes zero and the count for
the association is cleared.

The recommended value (from RFC 2960) for Path.Max.Retrans is 5.  The
recommended value for Assoc.Max.Retrans is 10.  The recommended values
are good for most purposes (except M2PA).

See RFC 4166 for brief discussion of deviation from recommended values
for SIGTRAN applications (e.g. section 3.2.3 for Max.Retrans
parameters.)

Setting Assoc.Max.Retrans to 10 ensures that at least two "paths" have
been tried to exhaustion on non-CMT SCTP before the association is
failed.  Which is completely reasonable.  Any application that requires
assurances that the association is viable for not more than a fixed
interval will have to implement its own hearbeats or ack timers (such as
M2PA does).

It is Path.Max.Retrans that has a greater effect on non-CMT SCTP
implementations: with M2PA and a typical T7 timer of 1 or 2 seconds, the
link will fail before the primary can switch, which is bad.  Careful
setting of Path.Max.Retrans, RTO.Min and RTO.Max or use of a CMT SCTP
can avoid this.

> 2.if one end pint fails to deliver the data using
> primary source IP should it use the other multihome
> source IP.

For the non-CMT SCTP yes: retransmissions SHOULD go to the most widely
dispersed source/destination IP pair that makes sense.  (For CMT SCTP,
they go to the "best" source/destination IP pair).

However, which source address is actually selected is more of an IP
routing matter than an SCTP one.  It is typical to assign a source
address of the outgoing interface to the packet.  Otherwise martian
sources could be detected by network monitoring and security devices.
Also, the theory is that if an IP packet can successfully reach its
destination from the interface, that a packet can be successfully
returned to the address of the interface.  If this condition does not
hold simply on the basis of IP address, not even a TCP connection could
be formed between the IP endpoints.  Misconfigured firewalls could cause
havoc, but it is not SCTP's place to compensate for misconfigured
firewalls.  Some raw socket based implementations indeed have no control
over source address and the IP stack simply assigns the source addres of
the outgoing interface.

Hope that helps.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/