Subject: Re: [tcpm] alternate IW proposal

From: Jerry Chu <[email-masked]>
Date: Thu, 2 Dec 2010 03:59:16 -0800

Joe,

On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch <[email-masked]> wrote:

>
> Jerry,
>
> In short:
>
> a) the receive window is an indication of the receiver's ability to reorder
> out-of-order packets; it limits what is sent primarily to avoid useless
> transmissions that the receiver will drop, not as a congestion control
> mechanism
>

Wrong. The main purpose of the receive window is to flow control a sender so
a faster sender
won't overrun a slow receiver, period.

>
>        yes, I find it odd that you are injecting control of the
>        receive window to correct for IW issues in your draft
>

What's wrong with that? Please give a specific badness of it? It works very
effectively. In
fact, I can't claim to be the inventor of this technique. It has been
mentioned in plenty of
RFCs. E.g., see RFC3150.

>
> 2) NO AMOUNT of in-connection adjustment of CWND has any effect on  the
> impact of a poor choice of IW
>

Yes it has. It limits the damage as Mark has poiinted out.

>
>        consider that if this were not true, then you would
>        not need to propose a new IW value; just as you do not
>        want to wait for the connection to converge, I am
>        concerned about the network impact until that convergence
>
> I have made the second point repeatedly. It would be useful to know if your
> continued misdirection of the issue is because don't agree with it, or some
> other reason.
>

Yes I can read and I understand you point. I guess it's more of the less
your subjective
definition of "impact". But in any case the impact of IW has gotten worst by
applications
opening many concurrent connections. I wish you had been as passionate
stopping that
trend as opposing a larger IW.

> Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Dec 2010 08:38:35 -0800

Jerry,

On 12/2/2010 3:59 AM, Jerry Chu wrote:
> Joe,
>
> On Sun, Nov 28, 2010 at 6:22 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Jerry,
>
>     In short:
>
>     a) the receive window is an indication of the receiver's ability to
>     reorder out-of-order packets; it limits what is sent primarily to
>     avoid useless transmissions that the receiver will drop, not as a
>     congestion control mechanism
>
> Wrong. The main purpose of the receive window is to flow control a
> sender so a faster sender

The receive window is for reordering AND also allows large 
bandwidth-delay products to have outstanding data during the round-trip 
delay until ACKs are received.

Neither of which has anything to do with the speed of the receiver per 
se. A fast receiver on a low-RTT link doesn't need a large receive window.

> What's wrong with that? Please give a specific badness of it?

You are confusing flow control with congestion control.

 > It works
> very effectively. In

That RFC makes the same error. The fact that you're using a hammer to 
drive in a screw doesn't make it a nail.

>     2) NO AMOUNT of in-connection adjustment of CWND has any effect on
>       the impact of a poor choice of IW
>
> Yes it has. It limits the damage as Mark has pointed out.

That's true ONLY for connections that last long enough to get that 
feedback. The curious thing is that
	a) such short connections is the reason you want to do this
	b) yet you seem to continue to want to ignore it as a factor

If anyone else on the list needs more info on these points, I'll be glad 
to followup, but at this point further exchanges with you on these 
points don't seem productive.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Thu, 2 Dec 2010 09:01:58 -0800

Joe, you don't need to preach TCP 101 to someone who has worked on TCP for
almost
20 years. Regardless, my being here is get some kind of larger IW proposal
done. As
long that can be achieved I am happy to acknowledge everything you said is
gospel :)

Best,

Jerry

On Thu, Dec 2, 2010 at 8:38 AM, Joe Touch <[email-masked]> wrote:

> The receive window is for reordering AND also allows large bandwidth-delay
> products to have outstanding data during the round-trip delay until ACKs are
> received.
>

> Neither of which has anything to do with the speed of the receiver per se.
> A fast receiver on a low-RTT link doesn't need a large receive window.
>
>

> That RFC makes the same error. The fact that you're using a hammer to drive
> in a screw doesn't make it a nail.

> If anyone else on the list needs more info on these points, I'll be glad to
> followup, but at this point further exchanges with you on these points don't
> seem productive.
>
> Joe
>