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 [email protected] https://www.ietf.org/mailman/listinfo/lwip
