Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Mon, 08 April 2019 06:53 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84105120157; Sun, 7 Apr 2019 23:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DDGTKH8jSfTF; Sun, 7 Apr 2019 23:53:49 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6631D1200CE; Sun, 7 Apr 2019 23:53:48 -0700 (PDT)
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 88E1F27914F; Mon, 8 Apr 2019 15:53:46 +0900 (JST)
Received: by mail-wr1-f51.google.com with SMTP id y13so14896394wrd.3; Sun, 07 Apr 2019 23:53:46 -0700 (PDT)
X-Gm-Message-State: APjAAAVKXcMMzRN+ACrDW+F6lz7CK+zGnQQinuvuOnuZs1UJ5cdlx82t b6jWd++kquWm86DTJ/GnFWAY+tjq/+v7WdtqrA8=
X-Google-Smtp-Source: APXvYqx6FrOYViJdEq7B+wtK+H+2O8shunD9delCBEvCJ7qXSFfW2wNLNa0r0hwUixlCLFRvqm4ScJGuaHNSCqj0S14=
X-Received: by 2002:adf:e949:: with SMTP id m9mr16586869wrn.237.1554706424433; Sun, 07 Apr 2019 23:53:44 -0700 (PDT)
MIME-Version: 1.0
References: <155402239346.12345.7871170827596594079@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA5053A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yf92bfdZCyfcQaHMt41SKO6CAQXOYEW2H++ZYQoXqKvpQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA51A15@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yeRK7RJ59jcmpXkwFX5_RniwGoBCcno3tNsCcFCJiRhsA@mail.gmail.com> <BYAPR16MB27904373EA2F32A9805B239AEA510@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB27904373EA2F32A9805B239AEA510@BYAPR16MB2790.namprd16.prod.outlook.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 07 Apr 2019 23:53:32 -0700
X-Gmail-Original-Message-ID: <CAO249yfhgvv3L9GxBQfYs-boeBecG+GhQSx90igDAuhA866WhA@mail.gmail.com>
Message-ID: <CAO249yfhgvv3L9GxBQfYs-boeBecG+GhQSx90igDAuhA866WhA@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dots-signal-channel.all@ietf.org" <draft-ietf-dots-signal-channel.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, Yoshifumi Nishida <nishida@wide.ad.jp>
Content-Type: multipart/alternative; boundary="0000000000002892c70585ff4c89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/P6GxYtOrxrrHTbg9xjSWSTMsVUQ>
Subject: Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 06:53:53 -0000

Hi Tiru,

On Thu, Apr 4, 2019 at 10:46 PM Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

> Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just
> like the figure 4) and the client cache the info.
>
> After certain period of time, the client will do happy eyeball again
> because other better connections might be available . But, in this case,
> how the cached info will be used?
>
>
>
> [TR] The cache expires after a specific time period. If the cache has not
> expired, the client uses the information from the cache. If cache has
> expired, the client performs happy eyeball again.
>
>
>
> It seems that an implementation that doesn't cache the info at all and
> does happy eyeballs at every 10 hours won't be allowed in this draft.
>
>
>
> [TR] No, but if the subsequent attempt is within few seconds after the
> first attempt of happy eyeball, it would trash the network. The endpoint
> may have to re-establish the (D)TLS session within few seconds for several
> reasons (e.g. TLS session got terminated, DOTS server rebooted NAT rebooted
> etc.).
>

Thanks for the explanation. The logic makes sense to me.
I think it would be good to articulate this a bit more in the draft.
For example, the figure 4 example explains the probing period, but doesn't
mention about the cache period.

Thanks,
--
Yoshi