> Yes, I understood although the truesize/len ratio might suggest that a bit
> larger window was possible.
What value did you expect?
Could you send me some tcpdumps showing window evolution?
It is interesting.
> there's plenty of bandwidth available which can not be utilized because
> of smaller window.
I tried to prove that it is never the case in real life.
When power is large, mtu cannot be small. These things are mutually
exclusive, except for some pathological configurations.
> Thanks for the PSC reference. Looks interesting. I agree for server
> configurations but this is really not a problem for your average
> workstation. It does not have a large number of simultanous connections
> and has plenty of spare memory.
Default configuration, builtin to kernel, is server configuration.
You (or redhat) may relax memory bounds for single user workstation.
> Current FreeBSD is happy to (by a glance in uipc_socket2.c so don't kill
> me if I'm wrong) to waste memory which I'd like as an option for Linux
Alas, I do not know anything about real current state of production
I know that year ago panic "out of mbuf clusters" was one of the most
frequent reason of crash of freebsd servers. I ma not sure that it changed.
Remember also about simple old attack feeding to freebsd single byte
packets at right edge of window. 8)
> bytes would be beneficiary too. Although both are used in sbspace() macro
> it seems sb_mbmax is pretty high. Incidentally they seem to have some of
> the infra-structure (soreserve) to guarantee enough memory for mbufs in
> place but unused.
Oh, no. This scheme is not different of linux one in practice
(ignoring some issues, which were severe bugs both in bsd and in linux)
Only units are different.
We really have some problems, not present in bsd, but they were
mainly because of forced linear memory allocation, rather than
to resource management.
Real scheme may base only on fair corelated resource allocation,
such heuristics are absent in bsd clones as well.
> I'll back out a bit and say that the MTU requirements of current GSM data
> are indeed imposed by the small bandwidth. However with current and
> forthcoming higher bandwidth wireless links there are entirely valid
> reasons for choosing a smaller MTU. The higher bit error rate for one, you
> don't need to retransmit as much. Link layer retransmit schemes might seem
> attractive at glance but are not in practice.
With high loss rate you will have cwnd of 1. It is TCP yet,
which is _not_ able to retransmit cleverly because its retransmission
algorithms are _strictly_ (MUSTed!) oriented to WAN congestion rather
than LAN loss.
It is pretty evident that lossy links must do error correction and
fragmentation at link layer. Or alternatively, TCP must be changed
drastically: entering loss notifications, disabling congestion
avoidance etc. etc. etc. Nobody wants this.
Seems, "thin long" people understand this, at least their output
wrt TCP looks very pessimistic and contains mainly negative results.
BTW linux-2.3 implements almost all their hints, which I estimated
as positive ones. 8)