Subject: [Lwip] Constrained TCP draft

From: Rahul Jadhav <[email-masked]>
Date: Sun, 16 Jul 2017 14:17:46 +0200

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 18 Jul 2017 11:25:26 +0200

Hi Rahul,

Thank you very much for your comments.

> 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

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.

> [RJ] I tried checking RFC5681, but could not relate to 5 MSSs for fast

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."

> keeping with the principle of lightweight operation" ... repeated on

Oh, thanks!

> ACKs and in most deployment such kind of control on the server/receiver is

Agreed.

> [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).

> 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*.

> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Jul 2017 11:09:12 -0700

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:
>
> 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
> 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] 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.
>
> [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
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 20 Jul 2017 09:54:30 +0200

Hi Joe,

Thanks a lot for your feedback.

Please find below inline responses:

> some "minimal" variant of TCP,

The very first version of the document had an (admittedly tentative)
"intended status" of "Best Current Practice".

However, after discussion and feedback from many folks, it was clarified
that the best approach for this document would be "Informational", and its
home would be the LWIG working group. So the main purpose of the document
is to describe how TCP can be configured in a suitable way for constrained
devices. The main purpose is not to define new mechanisms or a new TCP
variant. If during the process we identify that any new mechanism has to
be defined or a TCP specification requires some special modification for
constrained devices, TCPM would probably be the best home for that.

> subject to the following constraint:

Currently there is not a summary/analysis of this in the document. In
fact,  as explained above, we don't intend to actually define a new TCP
variant.

Anyway, we may consider the possible impact of each of the TCP
features/mechanisms analyzed in the document (section 4) on your four
items above, and even we might analyze whether any of the existing TCP
implementations for constrained devices (section 7) would not comply with
any of the four items.

> As is discussing this work in TCPM or at least TSVWG.

Definitely.

By the way, Michael Scharf has joined as an author of the draft.

Once again, thanks for your comments.

Cheers,

Carles

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Jul 2017 07:24:19 -0700

Hi, Carles,

> constrained devices, TCPM would probably be the best home for that.
It might be useful to make that more clear in the abstract and intro.

> implementations for constrained devices (section 7) would not comply with
If you're only changing TCP parameters within existing valid values, you
should be fine.

That can be tricky, though - as noted when the buffers cannot support
more than 2-3 segments (e.g., the ACK compression issue). That ends up
affecting you more than others, though.

IMO this doc should treat the issue of "configuring TCP" completely
separately from the analysis of implementations. The latter don't always
follow the specs, as we've repeatedly seen.

Joe