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

[Yoshifumi Nishida <[e-mail]>]

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