Hi, all, Scanning this doc, I had expected to see some "success criteria" up front.
In particular, I was expecting that this approach was intended to be some "minimal" variant of TCP, subject to the following constraint: This variant of TCP is intended to be compatible with current TCP, albeit with lower performance. I.e. 1) a constrained TCP client would always be able to connect with a compliant TCP server 2) a constrained TCP server would always be able to connect with a compliant TCP cllient 3) #1 and #2 MAY result in reduced performance for that client-server connection 4) #1 and #2 MUST NOT interfere with other client-server connections any more than other compliant TCP connections (i.e., MUST be "TCP-friendly") Is there any analysis or summary of this in the current document? If not, that's a good place to start, IMO. As is discussing this work in TCPM or at least TSVWG. Joe On 7/16/2017 5:17 AM, Rahul Jadhav wrote: > Hi Carles & co-authors, > > Foll are my comments for > the draft-gomez-lwig-tcp-constrained-node-networks-03: > > 1. Section 4.3 Window Size > [RJ] A single MSS implies max one in-flight segment ... While such a > mechanism sure will help reduce implementation complexity and the > buffer requirement on the sender, but it has a major problem with > delayed ACKs mechanism on the receiver. There is a hack > (http://contiki.sourceforge.net/docs/2.6/a01696.html) implemented in > UIP which circumvents this issue. > > 2. Section 3 Scenarios > [RJ] I feel the doc need not talk about unconstrained scenarios ... > For the constrained environment, the doc can classify between > different types of devices ... For example, a class A/B device with > possibly single and same send/recv buffer, a class B device with > possibly a separate send and recv buffer and a class C device with > multiple say 5 send/recv buffers (pooled for either send/recv). Note > that in case of uIP the send/recv buffers are same not only for TCP > but they are shared for other protocols as well ... > > 3. Section 4.3 "it may be useful to allow window sizes of at least > five MSSs" > [RJ] I tried checking RFC5681, but could not relate to 5 MSSs for fast > transmit/recovery... > > 4. Section 4.7 > [RJ] There is a redundant stmt ,, "Other TCP options should not be > used, in keeping with the principle of lightweight operation" ... > repeated on subsequent line. > > 5. Section 7.1 uIP > [RJ] May be this section can mention the Contiki "split hack" > technique (link ref'd above) to avoid delayed ACKs in case of sender > using single MSS. This helps because receivers now need not change to > disable delayed ACKs and in most deployment such kind of control on > the server/receiver is usually not possible. > > 6. Section 7.1 uIP "A buffer for outgoing data is not provided" > [RJ] The same buffer is used for both incoming and outgoing traffic. > > 7. Section 7.1 uIP "an application must be able to reproduce the same > packet that had been transmitted" > [RJ] Application cannot reproduce the same packet because application > does not control the tcp header values and thus additional buffer > space per connection is warranted (and is indeed used) in case of TCP > in uIP. > > 8. Section 7.3 RiOT > [RJ] Unlike uIP/lwip, the TCP numbers (prog mem) for RIOT-TCP aren't > mentioned ! Would be nice to know this difference. > > Regards, > Rahul > > > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip
_______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip