Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03
Yoshifumi Nishida <nsd.ietf@gmail.com> Tue, 21 January 2020 22:57 UTC
Return-Path: <nsd.ietf@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 D8B931200C3; Tue, 21 Jan 2020 14:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6PQNejfkzKaF; Tue, 21 Jan 2020 14:57:25 -0800 (PST)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 6D79E12002E; Tue, 21 Jan 2020 14:57:25 -0800 (PST)
Received: by mail-vs1-xe36.google.com with SMTP id b79so3007955vsd.9; Tue, 21 Jan 2020 14:57:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sDVFVFurxZggXiPh/Yht3crATUX1wVe8zRnh4KlqfuU=; b=CKNUFe/uykooREZ0ZzV1Thx8Bm1uIgsflcvXz0pJ/mENxUuvYaB2rxmQR2Me5mz5sm KdgONjhGlV/4AdJ9E6muS9lPGKbSYMB44fYpIRpPBm106Uh1Cc7o+mlWKZahjYcb3HL7 03cGpnwPHTta4kbTxOeTkE9JQpjRqgKkFYgJRhLodeXoU4MCicohrjTDCyMnz/qKga/D n37/DU66FBCMNHKimIKRJvovTpj/MADc5VTnV2GGfZ630ZlV3tLlQ2xdsfxEiHGQ6DZ0 iis9bs5wkPPC6KgPgI+mIc1zWyMCEVBbcvsjklNgXSCT4LzJXyBiIjae2EKVQz65cw6B VkTg==
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=sDVFVFurxZggXiPh/Yht3crATUX1wVe8zRnh4KlqfuU=; b=A6+KxlgZRj3vXLj5J1EYD5glN731UBS462jcNdm0pkKQ+dGEVld6waBo9gd9T8RNWj PzC+ZFy8iWEEv4TpgAqVGd/UCgQfNNzjz0FwrEauQrNIDkq3hO5cH1M9I9CbCCcbkW82 Ic3cytsPBahjjgAzvE5mTnYOGvf/65GTLpg4xXXZ1zedv9yVPTL+bD+QHmI/N1IHX58Z /aXYLdxCUP2NAUho8Vl0Qi6IpNOApFeyeIXxY+UzeC18RWbaewrKN+mJldJuRW1K8fi6 TTRuttiLmPQdjMihbSFa3US86sDN1nyEx7BJSCaeUZrOFw1I3eI0SyU7gMHAo4cmRs3x EFbQ==
X-Gm-Message-State: APjAAAVQXDQMAXKrf3Xa48PDvZ/QVh3kWLHEQuwhovqHSbuLlnBdboqo AaQtgRTgNYgBn5tLIRIawSR/2xgbgIuSAEYQe7ltkQ==
X-Google-Smtp-Source: APXvYqzSSST3sIV0x5dyQw4qmtIg2vW5cXxY8MT2CN1xAwcFA9syKK6gxw48X9tr48XudnbasKWRHRjqXRwe3HIcMOQ=
X-Received: by 2002:a67:ec12:: with SMTP id d18mr825572vso.129.1579647444487; Tue, 21 Jan 2020 14:57:24 -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>
In-Reply-To: <CALe60zAogQqC=62249kE3JLOg87Y=HTGycnkskPcyRL5VAwcyw@mail.gmail.com>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Tue, 21 Jan 2020 14:57:13 -0800
Message-ID: <CAAK044S43d5+=ZLasymJGw5Ck814n8QUhj8ADSqetTw5Cn3Qww@mail.gmail.com>
To: Justin Uberti <justin@uberti.name>
Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cc92ba059cae5486"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/yhq9rJ29TNSYXDpYB30rKNGwEac>
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: Tue, 21 Jan 2020 22:57:28 -0000
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