RE: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

[Yoshifumi Nishida <[e-mail]>]

Hi Karen,

Sorry for my very slow response. I've thought about this a bit more.
If you have comments or if I miss something, please let me know.

First, I would like to start from a scenario which PF increases error
count aggressively.
Let's assume we have an SCTP association consists of 2 paths and have
one outstanding packet. Now, I would like to think about the following
2 cases for this.

case 1: 1 path became unavailable and after for a while the 2nd path
became unavailable.
case 2: 2 paths became unavailable simultaneously

In case of case 1, if HB is on, SCTP detects an unavailable path and
mark them as inactive
eventually. consecutive error count is 0 until the 2nd path becomes unavailable.
Hence, PF and RFC4960 will have the same behavior in this case, so I
think we can exclude this.

Now, in case of case 1 without HB or case 2, I think RFC4960 behavior
will be like this:
   1: if t3-rtx expires doubled RTO for the destination address
   2: increase consecutive error count. if it exceeds AMR, terminate
the association
   3: choose one of paths (probably by round-robin) as new destination
of retransmission
   4: send a retransmit packet and start t3-rtx timer.

Even if the association goes into dormant state during this cycle, I
think the behavior will be
mostly similar.

In case of PF, the behavior will be something like this:
   1: if t3-rtx expires doubled RTO (data or HB) for the destination address
   2: increase consecutive error count. if it exceeds AMR, terminate
the association
   3: choose active path for new destination of retransmission. if
there is no active path,
       choose one of paths in PF state (probably by round-robin).
   4: send a retransmit packet and start t3-rtx timer.
   5: send a HB on the path where t3-rtx is not running and start t3-rtx.

So, the step 5 is the reason for the aggressiveness. In order to
address this issue, I think
we have the following 3 options.

Option 1:
   Don't increment consecutive error count when HB transmission is
timed out as you suggested.

Option 2:
   When we have to send data to the destination in PF state, don't
send HB to any PF destination.

Option 3:
   When there's multiple paths in PF state, send one HB at one time.

Here's my opinion on them.
I prefer not to do option 1 in PF. It seems to me that this should be
discussed for RFC4960
rather than PF. I would like to keep PF to be consistent with RFC4960
with regard to this.

So, I prefer option 2 or 3 although I don't have a strong opinion yet.
Or, we can adopt both option 2 and 3 if necessary.

Thanks,
--
Yoshifumi Nishida

2011/12/8  <Karen.Nielsen at tieto.com>:
> Hi,
>
> One additional comment to the draft.
> Not sure about whether it has been raised already though.
>
> The aggressive HBs sent on a potentially failed destination address should not contribute
> to the association overall error counter. I.e., a failed HB should not increment the associations error counter.
>
> At least that it how I firmly believe that things should be as the robustness of the
> association error count should not be impacted by the more aggressive HB probing
> (Also simply following the approach of RFC4960 Path Verification. 5.4 of RFC4960)
>
> Would it be possible to have this explicitly clarified in the draft ?
>
> Thanks.
> BR, Karen
>
> -----Original Message-----
> From: tsvwg-bounces at ietf.org [mailto:tsvwg-bounces at ietf.org] On Behalf Of Yoshifumi Nishida
> Sent: 16. september 2011 10:22
> To: tsvwg
> Subject: Re: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt
>
> Hi folks,
>
> Based on the michael's review, we have updated the sctp failover draft.
> We believe we addressed the comments we got so far.
>
> Please let us know if we overlook something or if you have more comments.
>
> Thanks,
> --
> Yoshifumi Nishida
> nishida at sfc.wide.ad.jp