Re: [Lwip] Constrained TCP draft

[Joe Touch <[e-mail]>]

Hi, Carles,


On 7/20/2017 12:54 AM, Carles Gomez Montenegro wrote:
> Hi Joe,
>
> Thanks a lot for your feedback.
>
> Please find below inline responses:
>
>> 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,
> 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.
It might be useful to make that more clear in the abstract and intro.

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