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

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

Lyndon, Randall,

What is the status of these bakeoff issues?

I am particularly opposed to the advice/solution in the following:

>     2.3 Heart beat issues
> 
>     Problem/Issue: The text is unclear on if the overall association
>     error count is stroked when a Heartbeat is not acknowledged.
>     Description: An implementation was not stroking the overall
>     association error counts when Heartbeats were missed. The individual
>     destination error counts were being stroked. When the peer "core
>     dumped" the association stayed up but both of the destination
>     addresses were marked unreachable.
> 
>     Advice/Solution: The specification clearly says (in Section 8.1) to
>     clear the association error counter when a heartbeat acknowledgement
>     arrives. However the specification fails to specify to stroke the
>     association error counter when an endpoint misses a heartbeat
>     ack. In section 8.2 it does detail to stroke and clear the various
>     destination error counters. The specification should be enhanced at
>     section 8.1 to specifically state to stroke the error counter for
>     the entire association if a heartbeat is missed.
> 
>     Found at: Bakeoff number 2 in Research Triangle Park 10/23/2000 -
>     10/27/2000

I don't believe that there was necessarily a problem with the
behavior of the implementation which kept the association up in
this case.  In fact, I see no reason to drop an association which
has all its destinations inactive unless there is something other
than a heartbeat which needs to be sent to the peer.  For completely
idle associations, temporary network disruptions should not abort
associations.

This is one of the nicer features of IP in general: that a connection
is virtual and, when it is idle, no physical connection need exist.
A natural ramification of this is half-open connections.

If the connection is not idle, retransmission or failure to transmit
DATA or SACK do peg the association error counts and the association
will be brought down shortly.

In the situation described in the draft, after the peer restarted,
it would send an INIT and get an INIT ACK with a cookie with tie tags
and upon receiving the COOKIE ECHO the implementation must restart the
association per spec.

If you change this as suggested, it would he highly likely that the
restart mechanism of SCTP will never be used.

I have other issues with the draft.  Are these issues still open?

--Brian

-- 
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:13:12 -0500

Brain:

Comments below...

> A natural ramification of this is half-open connections.

Interesting point.. But I don't see a problem either with pegging
the association error counter..

> will be brought down shortly.

Sack's will never cause a timeout or peg an error counter. Only data,
this
means that if two endpoints talk. And then one has nothing to say for
a while, all destinations are down your association may never drop..
on your side. Your SACK's will never get to the peer, and of course
eventually the peer would give up. In this case you definetly would
hit the restart case.. 

> restart mechanism of SCTP will never be used.

Well, getting into the "restart" case can happen for a couple of reasons
besides
the one above. If your app core dumps(for example) and then restarts
rapidly
you could get the collision. In the bake-off testing we have found it
very
difficult to create the restart condition anyway due to the fact that
the
surviving endpoint continues to HeartBeat. And of course the first HB to
the machine that had the restarting app causes a Abort to be sent if the
APP is not up...

This is only one of the potential places the restart scenario would
occur so
I don't think this is a big deal.

Cleaning the association up seems to me a better choice since it will
free the resources of the machine much faster. If you continue to
allow the association to exist you potentially fill up all your TCB's
with lots and lots of associations that can't talk. Granted it may be
nice in a network outage with no one sending data to take advantage of
this but then, on the first send, we have a interesting scenario. No
active destination and association up. This is completely unspecifed
in the spec (on purpose) as to how to handle this. Some may send 
on one of the interfaces anyway.. the other may hold waiting for the
HB's to bring back alive the association. Here could lie a problem... a
potentially never ending association since if you don't send DATA you
would
never start the timer that would kill the association.

Besides which, this was always the intent in the spec, its like so
many thing..we just did not get it put down clear enough :0

R

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