Hi Rahul,
Thank you very much for your comments.
Please find below inline responses:
> 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.
This is very interesting. We'll discuss this in the next update of the draft.
> 2. Section 3 Scenarios
> [RJ] I feel the doc need not talk about unconstrained scenarios ...
We actually only intend to talk about unconstrained devices when they
communicate with constrained devices. This appears to be a common scenario
(e.g. a constrained device talking to backend infrastructure).
> 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 ...
Yes, I agree with something along these lines. In fact it would be great
to find out if those device classes can be related with RFC 7228 device
classes, or if we can directly refer to the existing definitions in RFC
7228.
> 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...
Referring to a fragment of an email by Fred Baker, sent around one year ago:
"... name the packets in a given transmission burst A through F, and
presume that B gets lost. The sender should get an acknowledgement for A
when C arrives and duplicate acknowledgements when D, E, and F arrive. It
will retransmit B when the third duplicate ack arrives. In order to have
B, C, D, E, and F sent, the window has to be at least five."
> 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.
Oh, thanks!
> 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.
Agreed.
> 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.
Agreed, we'll update this accordingly (the intent was about a *separate*
buffer).
> 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.
Good catch, the sentence above needs to be modified to refer to the *data*.
> 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.
Same here ;-)
We've been in contact with a developer of the RIOT TCP implementation.
Let's see if we can be provided with more details on this.
Once again, thanks very much for your detailed comments.
Cheers,
Carles
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip
