[Lwip] Constrained TCP draft

[Rahul Jadhav <[e-mail]>]

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