Subject: [Tsvwg] Re: draft-stewart-ong-sctpbakeoff-sigtran-01.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 11 Apr 2001 21:05:05 -0500

Lyndon, Randall,

One more comment on heartbeat issues:

>     3.4 Concerns when you explicitly control the source address
> 
>     Problem/Issue: An implementation was explicitly controlling its
>     source addresses and during the loss of one network would lose the
>     whole association.
> 
>     Description: When controlling the source address an implementation
>     would always send with one set source address for both heartbeats
>     and data. When that address broke, the HeartBeat Ack's no longer
>     found their way back to the sender. This included both destinations
>     since the receiver of the Heartbeat always replied to the source
>     address. This led the sender to detect that its whole association
>     had broken when it actually still had a good path available.
> 
>     Advice/Solution:
[snip]

If an implementation does not know the availability of its own
interfaces it is pointless for it to select source address.
Even if this implementation chose a different source address,
there are equally probable failure scenarios which would have
the same end result.

If the peer knows that it has no route to a source address in a
HEARTBEAT message, it should send the HEARTBEAT ACK to an alternate
address.

There is a good possibility that a solution to the heartbeat case
might be to always send the HEARTBEAT ACK to the destination
address which would next be used if the primary failed.  That is,
to the destination address to which we will be sending
retransmissions, rather than the source address of the HEARTBEAT.
In the simple two-interface case, this should be the same
address in the absence of failure.  The RTO calculation would then
more properly address the likely RTO to be experienced upon
changeover from the primary address at either end.

If an implementation selects (or has IP routing select) a source
address which is outside those provided the peer in the INIT or
INIT ACK, and the peer is unable to determine the reachability of
destination address, the association is going to die before
Assoc.Max.Retrans.

The solution is for an implementation to know the availability of
its own interfaces: both for connection binding and for address
selection.  This is an IP thing, not an SCTP thing.  TCP has some
of the same issues, particularly for on-demand interfaces which
change their IP address dynamically.

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 12 Apr 2001 07:41:44 -0500

> destination address, the association is going to die before

Well, an implementation should not ever put a address in the source
address that is not part of the association or else it will get
an ABORT back for sure. If IP routing is selecting i.e. the source
is passed to the IP output routine has unspecified, then the
association had better have all the addresses bound in the association
(and have told the peer of them). If you have a dynamic IP address
thing going on then the add-ip draft better be present and used or
else you definetly are heading for a fall..

> change their IP address dynamically.

An implementation of course can know the availablity of the source
address but it can not possibly know the routeablility of the source
address with respect to the peer. This is why an SCTP should be using
address scoping int INTI/INIT-ACKs to deterimine what addresses to
send. In particular you probably don't want to send a INIT with a
10 based address (for example) to a peer that has a global IPv4 address.
Or likewise in IPv6 you would not send a Link.local address inside of an
INIT.

Has far as this instance in the draft, this was one of those thing where
the sender no matter what filled in its primary address in all messages
as the
source. This led it to a LOT of problems (besides the most obvious one
here). If
it had used either the unspecified address and let IP routing do the
fill in or
it had even brain-dead rotated amongst the source addresse, it would
have at
least continued to survive...

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127