> On Jun 24, 2016, at 2:49 AM, Carles Gomez Montenegro <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/lwip
