nanog mailing list archives

RE: TCP and WAN issue


From: <michael.dillon () bt com>
Date: Tue, 27 Mar 2007 23:24:39 +0100


What you want to see is large packets, as large as your end-to-end  
infrastructure can support.

Personally, I would prefer to see more people fixing the infrastructure
rather than accepting it as a limit. Install some Linux servers even if
all they do is run an application layer proxy to turn the TCP stream
from the LAN into something better suited for the WAN. They could use
UDP, compress the stream, consolidate small MTU packets into big MTU
packets, etc. I remember many years ago when a dentist asked me to help
with an urgent problem on his billing system. The system worked fine but
he split from his wife and had changed the corporate name of his dental
practice. He needed to produce bills under the new name, but the
software provider had gone out of business a couple of years earlier and
there was no source code. Fortunately, it was a UNIX based application
that used the print spooler for billing reports so I just inserted a
shell script to change "Pleasant Valley Dental Inc." to "Dr. Smith
Dental (1987) Inc." or some such. 

Fixing the infrastructure may also mean switching IP network providers
to get someone who supports bulk data transfers between data centers
with jumbo frames end-to-end.

Your application should be able to do that, potentially, and 
as other  
folks mentioned, your app can potentially be tweaked to open up  
multiple connections.  I think there are also NICs which do 
something  
of this sort, but it's not something I've personally used (maybe  
others have experiences they can relate?).

Tweaking apps generally turns out to be heavy-duty stuff with lots of
release control and testing. Also, the applications programmers
generally have a poor understanding of network issues. If you can
separate the applications stuff from the data transfer stuff, and tackle
the network issues first, then you will have an easier time of it.

--Michael Dillon


Current thread: