On 7/14/12, John Souvestre <johns@sstar.com> wrote:
> to accommodate the speed-latency product, thus avoiding the ACK delays. I
> believe that most current operating systems do a decent job of this.
Recent versions of Linux/Windows (post-XP) at least have a good enough
maximum window sizes available for general usage. In most cases
it's not worth the trouble of tuning it, at least not manually.
The major exception is high-bandwidth high-latency networks.
Examples: (more than 50 megabits/s end-to-end) and (more than 10ms
RTT latency)
> I have found two ways to compensate for some of the affects you describe.
> One is to be proactive, rather than reactive, about congestion. Cisco's
> (W)RED, for example. I've seen this improve matters on a busy circuit on
> more than a few occasions.
For an end user, that's good for congestion of the local connection
in the upload direction; as long as their total important traffic
needs don't exceed the 80%. Class-based traffic management can help
squeeze that last little bit of toothpaste out of the tube.
The limitation is it doesn't work end to end across the world.
In real-world applications, congestion is sometimes in the middle,
and sometimes at the far end network, on someone else's server.
RFC3168 ECN / Explicit Congestion Notification was supposed to help.
The problem turned out to be seriously broken Firewalls rejecting
packets with "Unknown" bits set.
http://lkml.indiana.edu/hypermail/linux/kernel/0009.1/0329.html
The feature was implemented over 10 years ago, and too this day,
ECN is supported in all the major OSes, but still off by default,
because of broken Firewalls,
and only really works with support on both client and server.
> The other, with regard to FTP, would be to "cheat" and use multiple
> sessions for a given file, thus ensuring that you are keeping the physical circuit
Multiple simultaneous streams works; there are download managers that
will do that.
> Is IPv6 any smarter with regard to packet sizes, both initially and when
> congested?
Well, TCP does not change at all with IPv6. One day SCTP could be a
successor to TCP.
TCP is probably overdue for refit, and addition of better reliability
intelligence as well, features such as path management or
multihomed host support (E.g. Advertisement of a hosts' alternate IP
addresses during connection establishment, so that a connection can
be load-balanced across all the peer's IP addresses, or
seamlessly/dynamically failed to an
alternate IP, for example, in case the link associated with one of
the IP addresses fails).
TCP does not support such things, e.g. "Failure" disrupts the
application; if an IP address you are connected to fails, you need a
brand new TCP connection to connect to the alternate IP; if a DNS A
record points to multiple IPs for a multihomed host, you only try to
connect to one, if the random IP you happen to pick is down, you fail
to connect (unless you have an intelligent application that finds all
IPs and tries each until a connection succeeds, which some web
browsers are not).
But TCP is widely deployed, and "good enough" for enough people,
that it's doubtful if it will change any time soon --- at least
with IPv6, there is a number resources exhaustion to encourage its
adoption.
IPv6 headers are approximately 20 bytes larger than IPv4 headers.
On the plus side, V6 headers are fixed length instead of variable length and
IP Packets are no longer checksummed.
Hosts that implement the IPv6 protocol are likely to be running a more
modern OS than Windows XP, as a side-effect they are likely to
implement CP window size scaling, fack/fast retransmits, and other
new features.
Old hosts that don't support IPv6 may be running such an old OS, that
the maximum possible setting for maximum window size is still 65,535
> Regards,
> John
> John Souvestre - New Orleans LA - (504) 454-0899
-- -JH ___________________ Nolug mailing list nolug@nolug.orgReceived on 07/15/12
This archive was generated by hypermail 2.2.0 : 07/25/13 EDT