On 6/24/2016 8:38 AM, Yoshifumi Nishida wrote: > 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"
There are two sides - what you do and how you handle the other side. I think it's short-sighted to expect to develop your side to do some specific variant of sliding window=1 when you have to deal with the other side NOT doing that. It's a LOT simpler to just do sliding window with a window of 1 - or even 2 (preferable). The code isn't that large, even for micro devices. > > > 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. As above, it does have to handle both sides. Given it has to handle the other side doing at least "window=1" (or preferably 2), that might be the simplest way forward - a lot simpler than creating a new mechanism and specifying it. Joe
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
