[tcpm] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks
Markku Kojo <kojo@cs.helsinki.fi> Thu, 02 May 2019 09:16 UTC
Return-Path: <kojo@cs.helsinki.fi>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4E120318; Thu, 2 May 2019 02:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 BEWIruCkZZa8; Thu, 2 May 2019 02:16:07 -0700 (PDT)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB180120312; Thu, 2 May 2019 02:16:05 -0700 (PDT)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 02 May 2019 12:15:59 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=8ZW61b5NB8GJ5plQz cNqN0yNAwKY712uuAd/rsqP+k0=; b=QMO7gjwae07Sfo+wMu/i/noz87lGO28b0 850mrcu1kCioMtITsDxRLHrYoIubsul5K6STu11RuKGAIoYQO4jddCd+YH0Oa4ig ulP88WoaDRDJVImvq28vc0LlmOrI6ioLE1wMkt5TZ9XJvy4TJH2nRa8lRCRe7D7u ru+u4Ta+DI=
Received: from hp8x-60 (85-76-8-120-nat.elisa-mobile.fi [85.76.8.120]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 02 May 2019 12:15:59 +0300 id 00000000005A014E.000000005CCAB54F.00003E45
Date: Thu, 02 May 2019 12:15:59 +0300
From: Markku Kojo <kojo@cs.helsinki.fi>
To: lwip@ietf.org, tcpm@ietf.org
In-Reply-To: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com>
Message-ID: <alpine.DEB.2.20.1905021157480.4247@hp8x-60.cs.helsinki.fi>
References: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/jc7DDpvaCqpVwZ2l1Dwpefw749Q>
Subject: [tcpm] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 09:16:10 -0000
Hi all, I have reviewed the -07 version of this draft for the WGLC. The draft is very useful for many developpers using or considering of using TCP in CNN scenarious. It has improved a lot from the previous versions but there are still a number of issues worth addressing. See comments below. Best regards, /Markku Sec 4.1. Title: Path properties - Would it be better to use "Addressing path properties" or something similar as TCP cannot (much) affect the properties? Sec. 4.1.1. If I understand it correctly, the discussion in this section is intended to be all about avoiding Path MTU discovery when running TCP oevr IPv6? Therefore, "Avoiding Path MTU Discovery in IPv6" would probably be a better title? In addition, to my understanding TCP implementations typically address the presence of TCP options such that they eat the necessary space for TCP options from the payload, not by increasing the IP datagram size if TCP options are present. For example, if SMSS is set to, let's say 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes) it will send only 1448 bytes of payload in a TCP segment? What the draft now says in this respect is on the safe side, but it might be overcautious. I don't remember any RFC saying how SMSS and adding options to a TCP segment are related. Maybe someone of the TCP implementors may shed more light to this how? The second but last para discussing IPv4 in this context is very confusing. In particular, the 2nd sentence "In IPv4, the MTU is 576 bytes." is simply incorrect. In IPv4 the requirement is that any host must be able to accept datagrams of up to 576 octets, but there is no upper limit of 576 for IPv4 MTU! Sec. 4.1.2. "In such traffic patterns, it is more difficult to detect packet loss without retransmission timeouts ..." -> "In such traffic patterns, it is more difficult and often impossible to detect packet loss without retransmission timeouts unless ECN is enabled ..." "When the congestion window of a TCP sender has a size of one segment, the TCP sender resets the retransmit timer, and the sender will only be able to send a new packet when the retransmit timer expires [RFC3168]. Effectively, the TCP sender reduces at that moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 segment per RTO, which can result in a very low throughput. In addition to better throughput, ECN can also help reducing latency and ECN can also help reducing latency and jitter." This text is somewhat inaccurate in terms of how ECN works if only a single segment is in flight (cwnd = 1 MSS) and confusing when it says "which can result in a very low throughput". The latter is kind a true, but also necessary to avoid congestion and, after all, it may result in higher throughput compared to the case where ECN is not used and retransmissions are needed. I'd rephrase the above to something along the lines: "When the congestion window of a TCP sender has a size of one segment and a TCP ACK with an ECN signal (ECE flag) arrives at the TCP sender, the TCP sender resets the retransmit timer, and the sender will only be able to send a new packet when the retransmit timer expires. Effectively, the TCP sender reduces at that moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 segment per RTO and reduces the sending rate further on each ECN signal received in subsequent TCP ACKs. Otherwise, if an ECN signal is not present in a subsequent TCP ACK the TCP sender resumes the normal ack-clocked transmission of segments [RFC 3168]. It might be also good to rearrange the text in the second and third paragraphs to disscuss the effect of retrasmission and timeouts more coherently. I may suggest text for this. Sec 4.2. "This section discusses TCP stacks that focus on transferring a single MSS." Maybe better: "This section discusses TCP stacks that allow transferring only a single MSS at a time." Sec 4.2.1. Last sentence: "For this use of CoAP, a maximum TCP window of one MSS will be sufficient." This is not necessarily true. If both TCP stacks involved allow a TCP window larger than 1 MSS and a CoAP request or response larger than one MSS is in use, it can be delivered more efficiently than in case where max TCP window is one MSS. Furthermore, this may also not be the case if a CoAP over TCP application uses short-lived TCP connections. Why? Because then the mandatory CSM message that each CoAP endpoint sends after the 3WHS may introduce an additional RTT as it cannot necessarily be sent during the same RTT with the first CoAP request/response. Of course, if the CSM message and the first CoAP request/response message fit into a single MSS and the TCP Nagle algorithm is disabled, such a single MSS window does not result in an additional RTT. Sec. 4.2.2. "A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit from supporting the following TCP options: Window scale [RFC7323], TCP Timestamps [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted [RFC2018]." It may be useful to mention that a TCP sender can benefit from Timestamps in detecting spurious RTOs that are quite likely to occur in CNN scenarios. Sec. 4.2.3. 2nd para: "A device that advertises a single-MSS receive window should avoid use of Delayed ACKs in order to avoid contributing unnecessary delay (of up to 500 ms) to the RTT [RFC5681], which limits the throughput and can increase the data delivery time." This should not appear as a generic recommendation as it is not correct for some typical usage scenarios such as request-response traffic where the node with a single-MSS receive window is the server sending the responses. With delayed ACKs it can biggyback the TCP ACK with the response if the response is sent before the delayed ACK timer expires, thus avoiding unnecessary pure TCP ACKs. So, here, like in Sec 4.3.2., it is important to indicate that it depends on the communication pattern whether delayed ACKs are useful or harmful. 3rd para: "A device that can send at most one MSS of data is significantly affected if the receiver uses Delayed ACKs, e.g., if a TCP server or receiver is outside the CNN." Again, this does not hold in all cases. E.g., if the server is outside of the CNN and request-response communication is used. The "split hack" is not advisable workaround. First for the reason stated in the end of the para, but more importantly because it simply does not necessarily even work; a TCP receiver is requited to acknowledge every second full-sized segment, but not two consecutive small segments. 4th para: "Similar issues happen when a sender uses the Nagle algorithm. Disabling the algorithm will not have impact if the sender can only handle stop-and-wait operation." Actually it does have an impact in some specific usage scenarios, e.g., with CoAP over TCP disabling the Nagle algorithm allows sending the mandatory CSM message and the first CoAP msg (request) and possibly also CSM and the first response without unnecessarily waiting for a TCP ACK of the CSM msg. This is of particular impact if short-lived TCP connections are in use with CoAP over TCP. Sec. 4.2.4. RTO is not estimated but calculated using estimated RTT and deviation from it. That is, modify: RTO estimation -> RTO calculation 2nd para: "[RFC6298] describes the standard TCP RTO algorithm." You may delete this sentence and cite RFC 6298 in the first sentence of the Sec 4.2.4 where the algorithm is first mentioned. 3rd para: "As an example, an adaptive RTO algorithm for CoAP over UDP has been defined [I-D.ietf-core-cocoa] that has been found to perform well in CNN scenarios [Commag]." Maybe not a good idea to cite the current version of CoCoA RTO algorithm (v3) that have been found also to have detrimental behavior? Sec. 4.3.1. "Assuming that Delayed ACKs are used by the receiver, the mentioned algorithms work efficiently for window sizes of at least 5 MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6 the segment 2 gets lost, the sender should get an ACK for segment 1 when 3 arrives and duplicate acknowledgements when 4, 5, and 6 arrive. It will retransmit segment 2 when the third duplicate ACK arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the size of 5 MSS would require 6100 bytes." The requirement for the window size to be of at least 5 segments does not hold if Limited Transmit is in use. Also, the requirement of at least 5 segments is valid only if the ACK for the segment 1 was held by the DelAck timer, i.e., the requirement holds approx. with 50% probability. That is, if the segment 1 got acknowledged (because there was also a segment before segment 1 and that was held by DelAck timer), only a window size of 4 MSS is needed. "For bulk data transfers further TCP improvements may also be useful, such as limited transmit [RFC3042]. Limited Transmit is not useful only for bulk data transfers but for any transfer that has more than one segment in flight. Small transfers tend to benefit more, because they are more likely to not receive enough dupacks. Sec. 4.3.1.1. "... a sender (having previously sent the SACK-Permitted option) can avoid performing unnecessary retransmissions, saving energy and bandwidth, as well as reducing latency." It might be worth mentioning also that SACK often allows for faster loss recovery when there is more than one lost segment in a window of data (i.e., recovery with less RTTs). Sec. 4.3.2. Disabling delayed ACKs on a client for infrequent request-response traffic with small messages might be advisable, too. It would allow an immediate ACK for the data segment carrying the response. This comment holds for Sec. 4.2.3 as well. Sec. 5.3. "A mean TCP NAT binding timeout of 386 minutes has been reported, while in some cases, inactivity timeouts are in the order of a few minutes [HomeGateway]. Reporting just the mean TCP NAT binding timeout from [HomeGateway] does not give a correct view of the results in this study, because the meaasured timeouts were highly variable and some devices had a very long timeout (or no timeout at all), yielding a very high mean timeout value. Therefore, we reported median and it would be more descriptive to report it here as well. The median of the measured TCP NAT binding timeouts in this study was around 60 mins, the shortest being around 2 mins. That is, clearly more than 50% of the devices had timeout shorter than RFC 5382 recommended minimum of 124 mins. In the light of these results, it may be hard to find a proper timeout value for the application-layer heartbeat messages, and it might be worth mentioning, I think. Nits: Sec 1: 1st para: Add references and cite 6LoWPAN, RPL, and CoAP. 3rd para: "At the application layer, CoAP was developed over UDP [RFC7252]." - this seems to cite UDP incorrectly while the intent is to cite CoAP. If you cite CoAP in the first para, you do not need to cite here at all. "This the main reason..." -> "This is the main reason..." 5th para: "Given the limited resources on constrained devices, careful "tuning" of the TCP implementation can make an implementation more lightweight." Instead of saying "tuning" of the TCP implementation, I'd say that careful selection of optional TCP features can make an implementation more lightweight (and improve operation in CNNs). 6th para: "This document provides guidance on how to implement and use TCP in CNNs. -> "This document provides guidance on how to implement and configure TCP as well as how TCP is advisable to be used by applications in CNNs. Sec 3.1., last para: high bit error rate -> high bit-error rate Sec 5., first sentence: "how a TCP stack can be used" -> "how TCP can be used"
- [tcpm] WGLC review of draft-ietf-lwig-tcp-constra… Markku Kojo
- Re: [tcpm] [Lwip] WGLC review of draft-ietf-lwig-… Carles Gomez Montenegro
- Re: [tcpm] [Lwip] WGLC review ofdraft-ietf-lwig-t… Markku Kojo
- Re: [tcpm] [Lwip] WGLC review ofdraft-ietf-lwig-t… Carles Gomez Montenegro