Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03
Justin Uberti <justin@uberti.name> Sun, 26 January 2020 01:09 UTC
Return-Path: <juberti@gmail.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3665120044; Sat, 25 Jan 2020 17:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaCHzjym3vfz; Sat, 25 Jan 2020 17:09:23 -0800 (PST)
Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36D912001E; Sat, 25 Jan 2020 17:09:22 -0800 (PST)
Received: by mail-lj1-f182.google.com with SMTP id n18so6942232ljo.7; Sat, 25 Jan 2020 17:09:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PINoLnR0QXH7UsujdJPR7vmAbDWtj2JpKOx6P4aOdjI=; b=qIYp4vYxWqLoGuost+k4eRfdt9WqiyO8DR8u2aD7jcrRwTHR5I4uL6tj2e3TvoBZQm KD8zVBR2aacofp8JSQxDYakY9a9NcB7pI+EDGdgjtKXyiqLOy4lRmc0S+rZWUhW093Ro OOOV5f4f9et+IUviBVu7wfYEybGlXUH1sIsB0y6JMqXPRZ1ufLdRDAnEaOw5varJsTB9 SIjr7iKUIwWpMIFfwPZEclntMEW//DnpNpVVK6/4f2/VBYoDgX2FNN/d0G7QIXKOBj2Z FbsZ2Ab/O833tlDqXXIUabYoDBh2aafRkHUFlaxfixiPeXyTeJn6wbC9mjhaa388ETd4 QyaQ==
X-Gm-Message-State: APjAAAU6M5AiG66wN1LoxWDzgXpm/LaQBh0fgvUs9bXST4r1d0V7WWoG FYS56jmR/QnQwnefbCcNYJWCVLKc7sh5ApQmcJA=
X-Google-Smtp-Source: APXvYqy+mrkmb+LGMaShQZpoUbdWT/AZa4GNg4GNd/HC5/RS4fPkb7ADM20O9bphz0QDWa3UIv35gBZO1uyncCwu+/w=
X-Received: by 2002:a2e:844e:: with SMTP id u14mr6239064ljh.183.1580000960969; Sat, 25 Jan 2020 17:09:20 -0800 (PST)
MIME-Version: 1.0
References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> <CALe60zBihCASoeOH5_H52vUHn4FxjqRGMvD44dcex-uuy3HOOQ@mail.gmail.com> <CAAK044S6jqMB_yM2tP5_2UG0y_+EyhhDRVHZWthz-R9PjrU3Fw@mail.gmail.com> <CALe60zAogQqC=62249kE3JLOg87Y=HTGycnkskPcyRL5VAwcyw@mail.gmail.com> <CAAK044S43d5+=ZLasymJGw5Ck814n8QUhj8ADSqetTw5Cn3Qww@mail.gmail.com>
In-Reply-To: <CAAK044S43d5+=ZLasymJGw5Ck814n8QUhj8ADSqetTw5Cn3Qww@mail.gmail.com>
From: Justin Uberti <justin@uberti.name>
Date: Sat, 25 Jan 2020 17:09:04 -0800
Message-ID: <CALe60zBTvwoOtQeBQNBVYZB0Bk-vv4LE1qp9yeOXtQLN1RNvyQ@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org
Content-Type: multipart/alternative; boundary="00000000000005ffc9059d00a484"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/2VVN4BldPdNnh3ORx316EICIeEs>
Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 01:09:25 -0000
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 <nsd.ietf@gmail.com> wrote: > > > On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <justin@uberti.name> wrote: > >> >> >> On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida <nsd.ietf@gmail.com> >> wrote: >> >>> Hi Justin, >>> >>> Thanks for the response. >>> I put my comments in lines. >>> >>> On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <justin@uberti.name> >>> wrote: >>> >>>> >>>> >>>> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < >>>> noreply@ietf.org> 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 >>>>> tsv-art@ietf.org 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 > > >
- [Ice] Tsvart last call review of draft-ietf-ice-p… Yoshifumi Nishida via Datatracker
- Re: [Ice] Tsvart last call review of draft-ietf-i… Justin Uberti
- Re: [Ice] Tsvart last call review of draft-ietf-i… Yoshifumi Nishida
- Re: [Ice] Tsvart last call review of draft-ietf-i… Justin Uberti
- Re: [Ice] Tsvart last call review of draft-ietf-i… Yoshifumi Nishida
- Re: [Ice] Tsvart last call review of draft-ietf-i… Justin Uberti
- Re: [Ice] Tsvart last call review of draft-ietf-i… Yoshifumi Nishida