Delayed ACKs are only a SHOULD in RFC 5681 and there is quite some wording on that SHOULD in Section 4.2, explaining that deviations are possible “after careful consideration of the implications”. I could imagine that this document could include such considerations.
Michael From: Lwip [mailto:[email protected]] On Behalf Of Yoshifumi Nishida Sent: Friday, June 24, 2016 5:39 PM To: Joe Touch Cc: [email protected]; Yoshifumi Nishida; [email protected] Extensions; [email protected] Subject: Re: [Lwip] [tcpm] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt] Hi Joe, On Wed, Jun 22, 2016 at 4:23 PM, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 6/22/2016 4:09 PM, Yoshifumi Nishida wrote: Hi Joe, On Wed, Jun 22, 2016 at 1:29 PM, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 6/21/2016 12:25 AM, Yoshifumi Nishida wrote: > I'm guessing clamping window size won't be a good way to make TCP > perform stop-and-wait operation and there is no good way for it. > Because TCP is basically not designed to perform stop-and-wait > operation, I think you'll have to describe the operation explicitly if > you want to do it. If the window is 1 MSS, then it ought to work just fine as you want. TCP is designed to run sliding window; stop-and-go is just a name for sliding window where N=1. I.e., it is designed for stop-and-go operation just fine -that's how a lot of transoceanic links behaved when sharing was high and capacity was low anyway. But, tcp's sliding window is not controlled by MSS. It uses byte to control it.. When you sent 0.1 MSS, TCP doesn't wait for an ACK before sending another 0.1 MSS. If Nagle is on (which it should be by default), here's what ought to happen: app writes 0.1 MSS > not a complete segment, but no unconfirmed data in the pipe yet, so TCP sends 0.1 MSS now app writes 0.1 MSS > not a complete segment, but there is unconfirmed data in the pipe, so wait TCP will wait until either the window size is more than 1 MSS (i.e., it resets to the full 1 MSS value) AND the available data is larger than 1 MSS until the pipe is clear. I.e., with Nagle on, you get stop-and-go but you don't have to wait for a full segment to kickstart the process. Yes, but we need to presume ACKs come back before Nagle's timer (typically 200ms) expires... Anyway, I am guessing this would not be a main point for the draft. In my understanding, the doc tries to provide guidance for lightweight TCP that can work under CNNs. So, my point was if we want to make stop-and-go TCP, it might be better to say "just support stop-and-go. Forget about Nagle or congestion control/loss recovery tricks, you don't need them for this simple scheme." rather than saying "support full-fledged sliding window, but window size is 1 mss, support Nagle, make sure it's always on and set Nagle timer long enough, etc" Note that existing TCPs don't work too well when the window size is lower than 2 (or any odd number of segments), because delayed ACK processing will introduce 200ms hiccups too. Yes.. This is a receiver side logic. We might want to know whether the draft focuses on using customized TCP on both sides or just one side. Thanks, -- Yoshi
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
