[e2e] TCP implementations in various OS's

[sthaug@nethelp.no]

> Another consideration is the number of flows. Are those long distance 
> fibers common for backbone connections or for connections with only some 
> few flows?

Long distance fibers pretty much always means backbone connections of
some sort.

> > Here again we have different goals. For my *core* network links, one
> > of my primary goals is to ensure sufficient capacity. In a normal
> > situation there is *no* congestion (throw bandwidth at the problem) -
> > and as far as I can see fairness doesn't enter the picture at all.
> 
> I don't see a conflict here. However, when we enable window scaling for 
> _all_ competing flows, there may a moderate level of congestion here, 
> because the flows' windows must achieve an equilibrium somehow.

You're assuming that the equilibrium must be reached because a flow is
competing against other flows. In *my* world it is also very common
that a flow reaches its equilibrium because it manages to saturate the
customer access link.

> > For my *customer* network links, the customer is paying for a certain
> > capacity. How the customer shares the capacity between different flows
> > is none of my business. Fairness is none of my concerns here either.
> 
> And it's not your business whether or not the customer utilizes or 
> underutilizes the line, I see.

Correct, the customer is free to underutilize the link. Many service
provider networks are based on statistical multiplexing, which implies
the customer is underutilizing the access link at least some of the time.

> > However, I *do* care about the customer having the possibility of using
> > the capacity he's paying for - and that means the customer needs to be
> > told about window scaling if expects decent TCP throughput on high RTT
> > paths.
> >
> I admit that I missed the situation of long distance _customer_ lines. 
> That's an actual shortcoming in my rationale.

The customer access link is seldom long distance. But the customer may
well wish to communicate (via TCP sessions) with something at the end
of a high-RTT path.

> However, can we agree that a good measure to prevent misbehaviour (which 
> _can_ result from a single flow using window scaling while the 
> competitors don't) is to enable window scaling actually on _all_ flows 
> or on _no_ flows? Although this might lead to some moderate level of 
> congestions even in lines with comparably moderate load?

I'm not prepared to agree on that yet. If you say "using window scaling"
then you also need to say something about which scale factor. If the
scale factor is 1, we should (at least in theory) get pretty much the
same behavior as a TCP implementation without window scaling, modulo
any software bugs due to more lines of code, less well tested code etc.
I haven't seen any good comparative study of TCP implementation behavior
with and without window scaling - this would certainly be interesting.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no