Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt]

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 1 Nov 2018 11:48:56 +0100

Hello Yoshi,

Sorry for the late reply, and thanks a lot for taking the time for your
review and for providing comments.

Please find below my inline responses:

> Hello,
>
> I've read the draft and I think the draft looks fine and mostly ready.
> I have some comments below..
>
> 1: Section 4.2.4:
>   "In that case, RTO algorithm tuning may be considered, although
> careful assessment of possible drawbacks is recommended"
>
> -> It might be better if we refer draft-ietf-tcpm-rto-consider here
> although it is not very certain the draft will be published at this
> moment? It seems to me the motivation of the doc fits the situation
> like this.

I agree. I guess we may cite draft-ietf-tcpm-rto-consider as an
informative reference for this section.

> 2: Section 4.3.1:
>    "These algorithms work efficiently for window size of at least 5 MSS"
>
> -> Just curious why this is 5? Is it because the use of delayed ack is
> presumed?
>      A receiver may have a chance to send an ack for segment 1 before
> segment 3 arrives.

Yes, the text was written under the assumption that delayed ACKs might be
in place. In the next revision we will explicitly indicate the assumption,
and update the related text as per your comment.

> 3: Section 5.3
>     CCN -> CNN?

Thanks for catching the typo!

>    "This overhead could be reduced by TCP Fast Open (TFO)"
>
> -> Yes, but the use of TLS is not mandatory in this draft. If an
> implementation utilizes TFO, we might want to mention about app level
> idempotency here.

Not sure I'm following you here. Could you please elaborate?

>    "TCP keep-alive messages are not very useful to..."
>
> -> We don't need to discuss reducing the interval of keep-alive here?

Currently, we have some text on this, although I agree it is a bit too
indirect. In the next revision, we will elaborate further.

Once again, thanks for your comments.

Cheers,

Carles

> Thanks,
> --
> Yoshi

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 1 Nov 2018 14:47:40 +0000

Chiming in...

> implementation utilizes TFO, we might want to mention about app level

We could add the following two sentences from RFC 7413 at the end of the paragraph:

  "However, TFO deviates from the standard TCP semantics, since the data in the SYN
   could be replayed to an application in some rare circumstances. Applications
   should not use TFO unless they can tolerate this issue, e.g., by using Transport
   Layer Security (TLS)."
 
> -> We don't need to discuss reducing the interval of keep-alive here?

We could add the following sentence (again adapted from RFC 7413):

  "Sending TCP keep-alive probes more frequently risks draining power on mobile
  devices [MQXMZ11]."

I am not sure how much more guidance we could give on picking an interval.

And the document already explains the benefits of application-layer heartbeat messages (if applicable).

Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 3 Nov 2018 00:07:47 -0700

Hi Caerles, Michael,

Thanks for the addressing the comments.

>    should not use TFO unless they can tolerate this issue, e.g., by using

Works for me.

> I am not sure how much more guidance we could give on picking an interval.

I agree. I think we don't need to talk about specific interval.
I just thought it would be good to mention it as this is one possible way
although it might not be a good approach in some cases.

Thanks,
--
Yoshi