Please see inline [TR3]
From: Dots <dots-bounces@xxxxxxxx> On Behalf Of
Yoshifumi Nishida
Sent: Tuesday, April 9, 2019 12:26 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>
Cc: ietf@xxxxxxxx; Yoshifumi Nishida <nishida@xxxxxxxxxxxxxx>; draft-ietf-dots-signal-channel.all@xxxxxxxx; dots@xxxxxxxx; tsv-art@xxxxxxxx; mohamed.boucadair@xxxxxxxxxx; Yoshifumi Nishida <nishida@xxxxxxxxxx>
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.
|
I put my comments in lines.
Hi Yoshi,
Please see inline [TR2]
|
CAUTION:
External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
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".
[TR3] The probing is for a scenario where the client is using TLS (over TCP) for the signal channel and probes to check if DTLS (over UDP) becomes available. If the probing finds DTLS over UDP is available, the client disconnects the TLS
over TCP and re-connects to the server using DTLS over UDP transport.
-Tiru
|
