Re: [Lwip] Constrained TCP draft

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