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

From: <[email-masked]>
Date: Thu, 8 Dec 2011 13:52:04 +0200

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: [email-masked] [mailto:[email-masked]] 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
[email-masked]

2011/9/16  <[email-masked]>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>        Title           : Quick Failover Algorithm in SCTP
>        Author(s)       : Yoshifumi Nishida
>                          Preethi Natarajan
>                          Armando Caro
>        Filename        : draft-nishida-tsvwg-sctp-failover-04.txt
>        Pages           : 16
>        Date            : 2011-09-16
>
>   One of the major advantages in SCTP is supporting multi-homing
>   communication.  If a multi-homed end-point has redundant network
>   connections, SCTP sessions can have a good chance to survive from
>   network failures by migrating inactive network to active one.
>   However, if we follow the SCTP standard, there can be significant
>   delay for the network migration.  During this migration period, SCTP
>   cannot transmit much data to the destination.  This issue drastically
>   impairs the usability of SCTP in some situations.  This memo
>   describes the issue of SCTP failover mechanism and discuss its
>   solutions which require minimal modification to the current standard.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-nishida-tsvwg-sctp-failover-04.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 9 Dec 2011 01:05:38 -0800

Hi Karen, thanks for the comment.

I think PF is not aggressive on the point you mentioned. Please point
out if I miss something.
In RFC4960, retransmitted data packets are sent to the failed
destination address and it will contribute to the
Association.Max.Retrans.
In PF, HBs are sent to the failed destination address instead of data
packets. The interval of HBs for the destination is RTO, which will be
the same as those of the retransmitted packets.
So, I believe both approach will have similar results on the
robustness of the association error count.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 9 Dec 2011 03:39:58 -0800

Hi Karen,

2011/12/9  <[email-masked]>:
> Hi,
>
> Please accept the follow up below.
>
>
> [Karen] In RFC4960 retransmitted packets will be send to most divergent path. Not to the PF path. But I suppose that you mean that as new data continues to be send on "PF" path in RFC4960, then the association error count will be hurt by the failure of these like it may be hurt
> by the failure of the aggressive HBs.

Sorry, that's what I meant. Thanks for the correction.

> [Karen] I agree for the case where there continuously is data flowing.
> But when there is not such data, then the aggressive HBs will impact the robustness of
> the association error count as there is no successful data that will reset it, as the successful retransmissions of data would.

Hmm. I see your point. In case where all path's status are active, but
somehow all of them become unavailable and one packet is sent. PF can
aggressively increase error count than RFC4960.. I would like to think
about how bad this is more.

>
> Generally, I have never understood why the faith of HBs should EVER contribute to the
> association error counter, EXCEPT when in idle state. And in this case, then in my opinion,
> it would suffice if it was the HBs on the primary path which were allowed to contribute to the association error counter. Indeed the association error counter is not there to ascertain whether all paths are available, only it should be there to ascertain whether some path of the association is available. In that respect HBs on non working (auxiliary) paths impacts the robustness of the association error counter.

It might be an interesting point. But, I'm not sure how much impact
this has. To make this effective, we need to presume the case where
all paths become unavailable, but at least one path comes back within
a certain amount of time. If this duration is too long or too short,
there'll be no difference even if we exclude HB's contributions. In
case of RFC4960, HB's contribution seems to be minor to me.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Alberto Cortés <[email-masked]>
Date: Fri, 9 Dec 2011 13:51:21 +0100

> destination address and it will contribute to the

I would like to point out that in RFC4960, retransmissions SHOULD be
sent to a different address than the one that failed (section 6.4),
and as far as I know, that's generally the case in all
implementations.

The probing of the failed address is performed by fresh, new
transmissions, not by retransmissions.

-- 
Alberto Cortés-Martín
Telematic Engineering Dept. at UC3M
http://www.it.uc3m.es/alcortes/index.html

---

From: <[email-masked]>
Date: Fri, 9 Dec 2011 11:23:16 +0200

Hi,

BR, Karen

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: <[email-masked]>
Date: Thu, 15 Dec 2011 13:51:15 +0200

Hi Nishida,

One more follow up, second thoughts :-)

I still believe that the aggressive HBs of the potentially failed feature SHOULD NOT contribute
to the association error counter.

One reason is the discussed situation when no data is flowing.
But actually also in the case where data IS flowing may the aggressive HBs 
have impact on the robustness of the association error counter. Indeed if data retransmissions
fail on other paths (while locating a new working data transmission path) due to
failure of other paths or simply due to random packet drops, the fact that we may have
aggressive step up of the association error counter due to the aggressive HB on the
potentially failed path does impact the robustness of the association error counter.

I would encourage for the aggressive HBs to be prescribed not to impact the association error counter.

I also (again) do believe that it is questionable in general why HBs sent 
on anything but towards the primary destination address should contribute
to the association error counter. But that is a general issue relevant to the 
base spec, not to this spec.

Thanks.

BR, Karen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 9. december 2011 10:23
To: [email-masked]
Cc: [email-masked]
Subject: RE: I-D Action: draft-nishida-tsvwg-sctp-failover-04.txt

Hi,

BR, Karen

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 20 Dec 2011 01:29:55 -0800

Hi Karen,

> I would encourage for the aggressive HBs to be prescribed not to impact the association error counter.

Is it possible for you to give me some sample scenarios?
I would like to think how bad this is more precisely.

> base spec, not to this spec.

I agree that this needs to go rfc4960, while I'm still not very sure
how this is effective.
In some cases, you might want to terminate association smoothly if
there's no available connections in order to save resources.
In case where you want to keep associations robust, I think you can do
it by increasing asoc.max.retr or increasing HB.interval or disabling
HB.

Thanks,
--
Yoshifumi Nishida
[email-masked]