Subject: [tsvwg] RFC4960 Section 8.1 and HB impacts on association error counter

From: <[email-masked]>
Date: Thu, 24 May 2012 10:23:58 +0300

Hi,

The purpose of this email is to solicit views on the extent of which the fate of
HBs should impact the association error counter of SCTP.

The purpose of the association error counter in RFC4960 is to monitor the aliveness/failure of the peer endpoint.
When speaking about aliveness is seems relevant to differentiate in between the aliveness of the peer endpoint
and the "aliveness of the association" in terms of the "capability of the association to forward data to the peer endpoint".
Whereas the aliveness of the peer of course is required for the association to be of any use,
then it is the latter that is of prime relevance for the SCTP Users and it is preferable if it is the latter type of "aliveness"
that governs association closures and thus the exact handling of the association error counter.
In this context it generally seems inappropriate for HBs to contribute to the association error counter.

Well - in idle situations only HBs can drive the association error counter and here it makes good sense that their fate
impact the association error counter (at least for the HBs that are transmitted on the current primary path).

But in the situation where data is being transmitted then it is problematic and even distorting to have the fate
of HBs transmitted over auxiliary paths impact the association error counter. By auxiliary paths I here mean paths
different from data carrying path(s). Reasons being:

Having successful HBs on some path reset the association error counter effectively results in that data may keep
on being retransmitted in vain many more consecutive times that what the AMR threshold indicates, either because
the intrinsic SCTP path selection is inadequate and not moves date (re)transmission to a working path or because
HBs are let through (e.g., due to their potential small packet size or due to HW HB ack mechanism) whereas data consistently is lost.

More importantly then if HBs that fail on auxiliary paths increment the association error counter, then in situations
where there are many paths and thus potentially many HBs transmitted within a short period of time
(even when randomly distributed there will or can be peaks), such failed
HBs diminish the room available in the association error counter/AMR for failed data (re)transmissions.
Effectively the failure of HBs on auxiliary back-up paths renders the association less robust
to survive data failures on the current primary path.

RFC4960 in section 8.1 stipulates that the fate of HBs shall contribute to the association error counter.
(Exception being HBs transmitted for Path Verification, but that is a different topic):

   An endpoint shall keep a counter on the total number of consecutive

   retransmissions to its peer (this includes retransmissions to all the

   destination transport addresses of the peer if it is multi-homed),

   including unacknowledged HEARTBEAT chunks.

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^If the value of this

   counter exceeds the limit indicated in the protocol parameter

   'Association.Max.Retrans', the endpoint shall consider the peer

   endpoint unreachable and shall stop transmitting any more data to it

   (and thus the association enters the CLOSED state).  In addition, the

   endpoint MAY report the failure to the upper layer and optionally

   report back all outstanding user data remaining in its outbound

   queue.  The association is automatically closed when the peer

   endpoint becomes unreachable.

   The counter shall be reset each time a DATA chunk sent to that peer

   endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT

                                                             ^^^^^^^^^^

   ACK is received from the peer endpoint.

   ^^^^^^

But it is also noteworthy (or is it?) that no RFC KEYWORDS are used in the formulations in this respect.

As there only seems to be down-sides of having HBs contribute to the association error counter (exception being idle situation)
I thus wonder whether the inclusion of HBs in Section 8.1. of the RFC was intended primarily to cover the idle situation and/or
if the lack of KEYWORDS somehow was motivated by similar concerns as the above that was discussed at the time of the definition of the feature ?

Along the same lines then I am wondering if it would be considered a breach of the RFC4960 if an SCTP implementation
chose to have the association error counter be driven only by the fate of data transmissions (except for the idle situation) ?

The issue becomes particularly relevant when considering the aggressive HB probing mechanisms
of http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05,
as there here can be very many Path monitoring HBs flowing on auxiliary paths compared to data transmissions.
But the issue is of generic nature and equally relevant for a basic RFC4960 SCTP implementation.

All thoughts are most welcome ! :)

Thanks in advance.

BR, Karen

PS: It is relevant to notice that path failure information based on unacknowledged HBs are considerable less
reliable than path failure input resulting from data T3 timeouts. This as fast retransmission procedures for data in many
cases may cover for single packet failures, whereas no mechanism is in place to cover for single drops of HBs.

---

From: Randy Stewart <[email-masked]>
Date: Thu, 24 May 2012 06:47:46 -0400

Karen:

In writing RFC2960 and later RFC4960 one of the fears I had
was that an overwhelming number of HB's would be being sent
by many endpoints. This could in theory flood the internet
with nothing but HBs. As such it was specifically left as
no MUST/SHOULD etc in the description of the HBs. This way implementations
could have a lot of lee-way in figuring out how they wanted to do HBs.

So yes, I think only counting the association error counter with HB's when
no data is in transit is a perfectly valid method. I would however continue
to count the path error counter on such HB's.

Note I have often thought we need two types of HB's. One that
is validating the association and one that is validating the endpoints "aliveness"
as well as its individual paths. Not that I have ever thought too deeply
on how to make this work. In the ideal case we would only have HB's between
two hosts over each of the paths, measuring the RTT and reach-ability of
the paths for all associations between a pair of hosts. Then when associations
were idle, we would have some sort of heartbeat so we could detect the peer
endpoint going away. One could even envision the HB's carrying a "list of ports"
in it that told the peer what associations were still up so that the association
HB's from say 100 associations would not be needed… of course all that is just
random thoughts early in the morning ;-)

R

On May 24, 2012, at 3:23 AM, <[email-masked]> <[email-masked]> wrote:

> and the “aliveness of the association” in terms of the “capability of the association to forward data to the peer endpoint”.
> then it is the latter that is of prime relevance for the SCTP Users and it is preferable if it is the latter type of “aliveness”
> All thoughts are most welcome ! J
>  
> Thanks in advance.
>  
> BR, Karen
>  

-----
Randall Stewart
[email-masked]

---

From: <[email-masked]>
Date: Thu, 24 May 2012 15:33:17 +0300

Hi Randy,

Thanks a lot ! 

This was exactly what I wanted to hear !

Yes, we shall continue to include HB failures  
in the path error counters, but I think that we will 
from now on exclude the feedback from HBs
in the association counter, except when there is no data.

BR, Karen

-----Original Message-----
From: Randy Stewart [mailto:[email-masked]] 
Sent: 24. maj 2012 12:48
To: Nielsen Karen
Cc: [email-masked]
Subject: Re: [tsvwg] RFC4960 Section 8.1 and HB impacts on association error counter

Karen:

HB's from say 100 associations would not be needed... of course all that is just

R

-----
Randall Stewart
[email-masked]