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

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

Lyndon, Randall,

Again, I take exception to the advice/solution in this case:

>     Problem/Issue: It is unclear in the heartbeat description on exactly
>     when to start, and stop heartbeating.
> 
>     Description: Some implementations where confused by receiving a
>     Heartbeat right away after start up. Other implementations where
>     confused by still receiving heartbeats after entering some of the
>     shutdown states.
> 
>     Advice/Solution: The specification is currently unclear as to when
>     heartbeating should begin and end. The specification should be
>     clarified to dictate that you should not send heartbeat after the
>     point of sending either a SHUTDOWN chunk or SHUTDOWN-ACK chunk and
>     you must not start heartbeating until you have reached the
>     established state. The specification should also be clarified to
>     state that you MUST respond to a Heartbeat after entering
>     COOKIE-SENT state until you reach the closed state.
> 
>     Found at: Bakeoff number 2 in Research Triangle Park 10/23/2000 -
>     10/27/2000

If an implementation does not send HEARTBEAT while in
SHUTDOWN-SENT state then it cannot know the availability of or
current RTO calculations for destinations to which it may still
have to transmit a SHUTDOWN chunk (in response to received DATA)
or as a retransmission upon shutdown timer expiry.

The same is true for SHUTDOWN-ACK-SENT.

The rationale as to why this is necessary is that the SHUTDOWN
or SHUTDOWN ACK chunk may get lost.  When my shutdown timer
expires, I must know the availability of destination addresses
for selection of destination address for retransmission of
SHUTDOWN or SHUTDOWN ACK or for transmission of a new SHUTDOWN
acknolwedging received DATA chunks.

Heartbeating can certainly not stop until SHUTDOWN COMPLETE is
sent or received, which the current specification permits.

While an association is opening, it appears possible that an
implementation may ignore a HEARTBEAT received in COOKIE-WAIT
state.  In this case, the peer is in the CLOSED state and should
not be sending HEARTBEATs.  The behavior is neither here nor
there.  Responding to the HEARTBEAT in COOKIE-WAIT would not
cause any problems either.  As suggested in the advise/solution,
it is clear that HEARTBEATs should be acknowledged after
COOKIE-ECHOED state has been entered (particularly because the
COOKIE ACK may have been lost).

Putting the two together, it appears that there is no problem
with responding to HEARTBEAT with a HEARTBEAT ACK in all states
other than CLOSED.  And although an implementation should not
generate HEARTBEAT in the CLOSED state, who cares.  It is clear
that if the endpoint has a TCB and the HEARTBEAT is not OOTB,
there is no reason why it cannot respond to it with a HEARTBEAT
ACK.

Therefore the spec does not need to be changed.

On the other hand, treatment of HEARTBEAT received OOTB needs to
be addressed due to the half-open case of my previous note: If
peers always respond to an OOTB HEARTBEAT with an ABORT, a
restarting endpoint will never get a chance to retstart an
association after a reboot, because it will ABORT all half-open
associations before attempting to reopen them.  Although this is
consistent with TCP behavior and response to half-open
connections on restart (send RST = connection reset by peer), it
would also mean that the SCTP restart scenario will never
practically occur.  The SCTP restart procedures were especially
intended to address restarting endpoints, yet ABORT in response
to OOTB HEARTBEAT limits their usability.

The treatment of OOTB HEARTBEAT messages needs to be changed to
"silent discard".

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

> or as a retransmission upon shutdown timer expiry.

When you send a SHUTDOWN and enter the shutdown-sent state, you
had a reasonable RTO caclulation, since you just sent DATA up until
the SHUTDOWN. The HB's happen at a very slow rate anyway.. not enough
to keep the RTO updated to such a find degree... I believe the default
HB is once every 30 seconds. This is a long long time in terms of
keeping the RTO current and I don't see how stopping HB's will make
that big of difference. Once the SHUTDOWN state is entered the
peer will not accept new data from its app. Even in real worse
case scenarios, 30 seconds (until the next HB) will allow a LOT
of data to be sent by the peer. And if the peer is sending data
(and not the SHUTDOWN-ACK) you are responding to every packet
with a SHUTDOWN and SACK bundled (or seperate).  This means
you are resetting the last known timer constantly anyway.

> The same is true for SHUTDOWN-ACK-SENT.

And once again, in the SHUTDOWN-ACK-SENT state it is highly
unlikly to take more than 30 seconds to get your SHUTDOWN-COMPLETE
back. And if you do hit more than one retransmission most likely
you will end up  that the peer did get one of the shutdown-ack's and
is now sending you a SHUTDOWN-COMPELTE with the T bit set since it
does not have the association.

> sent or received, which the current specification permits.

At the final stage of the association life I don't see how
it makes that much of a difference. Right before the shutdown or
shutdown-ack is sent you WILL have known the reachability and state
of your networks from both your last DATA and the last sets of
hearbeats that have occured. It is highly doubtful and a REAL REAL
corner case where the shutdown sequence is going to take more than
30 seconds (the time that it will most likely take for yet another
HB to be sent). If it does you have one end still pumping lots of
data at the other.. and that seems rather unlikely in an application
if it uses any sense about when to issue the shutdown... which it 
should (yeah, I know applications do do stupid things sometimes but
then most likely it will get an error when the shutdown arrives).

> Therefore the spec does not need to be changed.

I don't think it is a bad idea to specify when HB's should begin and
end. This was the consensus of the SCTP implementors that were
at the bake-off... and I think it in general is a good idea..

> associations before attempting to reopen them. 
 
This is the design intent of the HB mechanism. It is to be used
to clean up state of stray associations.. I don't expect this
to change..

>                                                 Although this is

This is true, has I said in my earlier email... 

> The treatment of OOTB HEARTBEAT messages needs to be changed to

Nope, I don't see this has a good idea. The whole reason we put this in
is
so that cleanup would occur quickly. There is even notes in RFC2960 
advising you that if you turn off HB's then you lose this
cleanup feature and one must consider this when playing with the HB
timer. 

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