Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03

[Yoshifumi Nishida <[e-mail]>]

Hi Justin,

The text looks good to me. Thanks for updating.
--
Yoshi

On Sat, Jan 25, 2020 at 5:09 PM Justin Uberti <[e-mail]> wrote:

> Added the bolded text below. Full details at
> https://github.com/ice-wg/draft-ice-pac/pull/20.
>
>
> *The RECOMMENDED duration for the timer is equal to the
> agent'sconnectivity check transaction timeout, including all
> retransmissions. *
>
> *When using default values for RTO and Rc, this amounts to 39.5 seconds,*
>
> *as explained in <xref target="RFC5389" />, Section 7.2.1.*
> *This timeout value is chosen to roughly coincide with the maximum [...]*
>
>
> On Tue, Jan 21, 2020 at 2:57 PM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>>
>>
>> On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <[e-mail]> wrote:
>>
>>>
>>>
>>> On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida <[e-mail]>
>>> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> Thanks for the response.
>>>> I put my comments in lines.
>>>>
>>>> On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> Reviewer: Yoshifumi Nishida
>>>>>> Review result: Almost Ready
>>>>>>
>>>>>> This document has been reviewed as part of the transport area review
>>>>>> team's
>>>>>> ongoing effort to review key IETF documents. These comments were
>>>>>> written
>>>>>> primarily for the transport area directors, but are copied to the
>>>>>> document's
>>>>>> authors and WG to allow them to address any issues raised and also to
>>>>>> the IETF
>>>>>> discussion list for information.
>>>>>>
>>>>>> When done at the time of IETF Last Call, the authors should consider
>>>>>> this
>>>>>> review as part of the last-call comments they receive. Please always
>>>>>> CC
>>>>>> [e-mail] if you reply to or forward this review.
>>>>>>
>>>>>> Summary:
>>>>>>    This document is straightforward and almost ready for publication,
>>>>>>    but it will be better to clarify the following points.
>>>>>>
>>>>>> 1: How to calculate the PAC timer is not very clear to me.
>>>>>>    Does this draft recommend to use the equation described in Section
>>>>>> 14.3 of
>>>>>>    RFC8445 or are there other ways? I think this would be better to be
>>>>>>    clarified.
>>>>>>
>>>>>
>>>>> Yes, the equation in 14.3 coupled with the STUN backoff guidance in
>>>>> https://tools.ietf.org/html/rfc5389#section-7.2, although these
>>>>> values are just recommendations. The point here is to say that whatever is
>>>>> used for the check timeouts should also be used for the PAC timer.
>>>>>
>>>>
>>>> Right. I was just wondering that it might be useful to mention the
>>>> recommended value can be calculated from the equation.
>>>> If the readers know what'll be the recommandation value, I think they
>>>> can have some ideas about whether their values are conservative or
>>>> aggressive.
>>>>
>>>>
>>>>>
>>>>>> 2: I presume this draft only focuses on UDP candidates, but I think
>>>>>> clarifying
>>>>>> it would be useful.
>>>>>>    I am also wondering how to treat PAC timer if agents have a mix of
>>>>>> TCP and
>>>>>>    UDP candidates.
>>>>>>
>>>>>
>>>>> The guidance here applies to both UDP and TCP candidates. It would not
>>>>> be unheard of for a server to only offer TCP candidates, and the client to
>>>>> offer zero candidates, as in S 3.1.
>>>>>
>>>>
>>>> I see. But, in this case, will there be a need to update RFC6544?
>>>> Also, if we set PAC timer around 500 msec but establishing a TCP
>>>> connection takes longer than it, should it be considered failed or not?
>>>>
>>>> Given RTO floor of 500 ms and exponential backoff per 5389, the PAC
>>> timer will typically be around 30 seconds. Perhaps a note to this effect
>>> would clarify this and point #1.
>>>
>>
>> Sounds like an idea. I think it will be useful for readers to add a note
>> for it.
>> Thank you so much.
>> --
>> Yoshi
>>
>>
>>
>