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

[Yoshifumi Nishida <[e-mail]>]

Hi Tiru,

I put my comments in lines.

On Mon, Apr 8, 2019 at 1:40 AM Konda, Tirumaleswar Reddy <
[e-mail]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:* Yoshifumi Nishida <[e-mail]>
> *Sent:* Monday, April 8, 2019 12:24 PM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* Yoshifumi Nishida <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Yoshifumi Nishida <[e-mail]>
> *Subject:* Re: [Dots] Tsvart last call review of
> draft-ietf-dots-signal-channel-31
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> On Thu, Apr 4, 2019 at 10:46 PM Konda, Tirumaleswar Reddy <
> [e-mail]> 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.
>
>
>
> [TR2]
>
> Sure, we can update the text as follows:
>
>
>
> Note that the DOTS client after successfully establishing a connection
> MUST cache information regarding the outcome of each
>
> connection attempt and the cached information should be flushed when its
> age exceeds a system-defined maximum on the order of few minutes (e.g. 2
> minutes).
>
> If the DOTS client has to re-establish the connection with the DOTS server
> within few seconds after the Happy Eyeballs mechanism is complete,
>
>   caching avoids trashing the network in the presence of DDoS attack
> traffic.
>

Thanks for the updates. But, one thing.. The text suggests cache period
would be the order of few minutes.
But, this value seems to be much smaller compared to "probing SHOULD NOT be
done more than every 24 hours".
--
Yoshi