That's an amazing CC list :-) I would suggest moving to expertly one of those working groups.
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. 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 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...
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
