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

[Alberto Cortés <[e-mail]>]

On Fri, Dec 9, 2011 at 10:05 AM, Yoshifumi Nishida
<[e-mail]> wrote:
> 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.

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.


> 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
> [e-mail]
>
>
> 2011/12/8  <[e-mail]>:
>> 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: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>>
>>
>> 2011/9/16  <[e-mail]>:
>>> 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
>>> [e-mail]
>>> 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
>>>



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