North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: TCP and WAN issue

  • From: michael.dillon
  • Date: Tue Mar 27 18:24:30 2007

> 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