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