Re: [Lwip] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Fred Baker (fred)]

> On Jun 24, 2016, at 2:49 AM, Carles Gomez Montenegro  
> wrote:
>> 
>> I imagine that the reason for a fixed effective window of one packet is to
>> limit the issues with packet resequencing and congestion control. I think
>> you still want to facilitate the Fast Recovery heuristic, which requires
>> that you support an effective window of five. To work that through, later
>> 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.
>> 
>> I can see making that optional, but I don't think it should be precluded.
> 
> The reason for originally proposing a fixed effective window of one packet
> is simplicity. There have been concerns in IoT-related WGs regarding the
> 'complexity' of TCP, and I remember specific comments expressing a goal
> for the confirmable functionality in CoAP to be simple, and to avoid
> 'reproducing TCP complexity in CoAP'.
> 
> As the current stop-and-wait approach for CoAP confirmable messages seems
> to be acceptable for the CoAP community, our draft aims to show how a
> similar behavior can be achieved also with TCP (now that CoAP can also be
> used over TCP).
> 
> Nevertheless, I agree that a 'MUST' for the stop-and-wait approach is
> maybe a bit radical. Maybe one option could be to recommend this operation
> without precluding the use of greater window sizes (in terms of segments),
> e.g. to benefit from mechanisms such as Fast Recovery if people want to
> use them?

That would make sense. Mentioning the Nagle algorithm would also be valuable.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Carles Gomez Montenegro]

Hi Fred,

Thank you very much for the great feedback!

> That's an amazing CC list :-) I would suggest moving to expertly one of
> those working groups.

Yes... :-)

(Still, keeping LWIG and TCPM...)

> Carsten's comment that TCP sessions are likely to be asymmetric, with a
> constrained node talking to an unconstrained node, is an important one.
> This seems like an excellent place to note the Robustness Principle -
> "conservative in what you send, liberal in what you receive". If the
> constrained node is limited to a profile like yours, and a peer tries to
> negotiate the use of other options, or simply sends other options, you
> want the CNN to act on what it understands and ignore the rest.

Yes, I agree that the implications of this asymmetric scenario have to be
highlighted, and also agree with the direction you indicate.

> There are a couple of constants in the draft that caught my attention.
>
> I imagine that the reason for a fixed effective window of one packet is to
> limit the issues with packet resequencing and congestion control. I think
> you still want to facilitate the Fast Recovery heuristic, which requires
> that you support an effective window of five. To work that through, later
> 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.
>
> I can see making that optional, but I don't think it should be precluded.

The reason for originally proposing a fixed effective window of one packet
is simplicity. There have been concerns in IoT-related WGs regarding the
'complexity' of TCP, and I remember specific comments expressing a goal
for the confirmable functionality in CoAP to be simple, and to avoid
'reproducing TCP complexity in CoAP'.

As the current stop-and-wait approach for CoAP confirmable messages seems
to be acceptable for the CoAP community, our draft aims to show how a
similar behavior can be achieved also with TCP (now that CoAP can also be
used over TCP).

Nevertheless, I agree that a 'MUST' for the stop-and-wait approach is
maybe a bit radical. Maybe one option could be to recommend this operation
without precluding the use of greater window sizes (in terms of segments),
e.g. to benefit from mechanisms such as Fast Recovery if people want to
use them?

Cheers,

Carles


> The two hour lifetime of a session also seems heavy-handed (and I would
> say the same about a two hour minimum keep-alive interval). I might
> suggest that the implementor or operator should figure out how many TCP
> peers a given system is likely to end to communicate with on a regular
> basis (the number of TCP-based application instances it runs being a
> possible guideline for that), and be required to have at least that many
> TCBs plus one. It should then allocate a TCB to a new session from that
> pool on an LRU basis, so that TCBs associated with active sessions tend to
> stay open. If you do that, I don't think you need to specify anything
> about session duration.
>
> My two yen...
>


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

Re: [Lwip] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

[Scharf, Michael (Nokia - DE)]

Just out-of-curiosity: In 1981, when the current TCP spec was published, end 
hosts had significant processing and memory limitations. Quite a bit of the TCP 
protocol mechanisms were designed to deal with senders and receivers that have 
very small buffers, e.g., of the order of the maximum segment size.RFC 793 is 
very carefully designed to deal with these constraints. And current TCP 
implementations are still backward compatible to RFC 793.

When quickly scanning through this document, some observations (the list is not 
comprehensive): 

- TCP counts window sizes in bytes, which 
draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. 

- Out-of-my-head, nothing prevents a TCP sender from limiting the congestion 
window to a small window (e.g., one MSS). This basically turns TCP into a 
stop-and-wait protocol. A TCP sender can unilaterally decide to limit its 
congestion window if it wants to simplify its implementation. I am not sure if 
RFC 2119 language is needed for that at all.

- A TCP receiver can use the receive window to prevent the sender from sending 
data, e.g., if it can only deal with one MSS. It may be interesting to look 
into whether advertising a maximum receive window e.g. of at most one MSS would 
solve some of the problems discussed in the draft.

- TCP options will only be enabled if supported on both ends and a 
standard-compliant TCP stack only has to support the MSS option (more 
precisely, option kinds 0, 1, and 2). An implementation that does not want to 
use any additional TCP features does not have to implement support any of those 
options. However, to be compatible with RFC 793 the option kinds 0, 1, and 2 
have to be parsed in SYNs and thus basic support for option parsing in SYNs is 
required anyway. If the basic support for option parsing in SYNs is in place 
(which is not very complex code), it seems easy to process any other options 
that may be present in the SYN as well, and just ignore them. Thus, I do not 
understand what added value a MUST has that "forbids" TCP options that may 
typically not be negotiated in the environments addressed by this document.

- If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., 
because it advertises very small receive window), the delayed ACKs in TCP may 
offer some opportunities for optimization, e.g., a receiver could want to turn 
them off delayed ACKs when it advertises a very small receive window. I believe 
the document could look into that space.

- There are quite a number of differences between using TCP only inside a 
controlled environment, or using TCP with endpoints that are located in the 
Internet. I would recommend that a document explicitly discusses both variants, 
as design trade-offs could be different. And I would assume that one of the 
reasons for picking TCP would be to at least have the option of end-to-end 
transfers over the global Internet.

- ... (there is more)

In general, the TCPM list is followed by quite a number of different TCP 
implementers and there is some expertise on the original RFC 793 design 
decisions. If the intention of this document is e.g. to define up a minimum set 
of TCP features required for a stop-and-wait operation and with very small 
buffers, I'd assume that relevant expertise would be on the TCPM list.

So, it might make sense to keep the TCPM list in the loop. Presenting the 
document in TCPM may also be an option the authors may want to think about.

Michael

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip