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 [email protected] https://www.ietf.org/mailman/listinfo/lwip
