[Guy Harris <gharris@xxxxxxxxx>]

Phillip Wilson wrote:
> Hi Guys
>
> Not sure if I'm asking the right people, or even the right question, but I'm
> willing to try anything right now.
>
> This problem started a couple of days ago and it's taken me until this morning
> to get a handle on it. We have a 2Mbps ADSL connection shared between 25 users
> for web browsing and e-mail. We have our own SMTP mailer inhouse that forwards
> all outgoing mail to our ISP. A couple of days ago people started to complain
> that web browsing was okay one moment, but unusably slow the next. Pinging one
> of our ISPs nameservers during a slow period showed average response times of
> 2500ms where we normally have 30ms. The connection is still alternating between
> fast and slow periods.
>
> This morning I noticed that the connection slows down while our SMTP mailer is
> sending mail to our ISP

Hopefully you don't have 25 users trying to use all of the limited 
upstream bandwidth of your ADSL connection to send mail. :-)

If you expect to have a lot of users sending mail - or doing any other 
form of uploading - so that the upstream bandwidth is being heavily used 
for a significant amount of time, perhaps the "A" in "ADSL" is the 
problem, and you should look into getting SDSL.  ("ADSL" was originally, 
I think, designed for video to the home, with the upstream channel 
acting as a control channel; it's still somewhat oriented towards 
typical home Internet use, with a lot more downloading than uploading 
being done.)

> I downloaded and installed the Windows version to my laptop and captured all
> data while an email message was being sent to our ISP. Filtering to show only
> packets from my mail server to my ISPs mail server showed that things start
> normally with the usual SMTP hand shaking stuff, then things appear to go a bit
> awry. Almost every packet says "TCP Window Full" in the Info column. These
> lines are in red text on a black background which makes me thing they're not
> good.

It means that your ISP's mail server's TCP implementation has told your 
mail server that it has room for N bytes of data on the connection 
between them, and N is small enough that your mail server can send that 
much data in a single packet - which it does, so as to get as much data 
sent as possible per packet (so that the fixed per-packet overhead is as 
small a percentage as possible of the data being sent).

I'm a bit surprised that the window is that small, but perhaps they're 
trying to keep any single customer's mail server from chewing up all the 
bandwidth or buffer space.

However, I doubt that's your problem; in fact, if they had a *smaller* 
window, that might *improve* your response while mail is being sent, 
even though it'd take longer for the mail to be sent.

The problem here is *probably* latency.  While a TCP segment full of 
mail data is being sent, no other packet can be sent on the link; the 
larger the TCP segment is, the longer that packet is, and the longer 
that other transmissions will have to wait.  That might significantly 
delay, for example, pings (as the ping won't be sent until the TCP 
segment has been sent).

2500ms is 2.5s, and if your uplink is 800Kb/s, that's 100KB/s, so that's 
250KB; if it's 400Kb/s, that's 125KB.  That's a bit bigger than, for 
example, a typical Ethernet packet, and hence bigger than the TCP 
segments I'd expect your mail server would be sending, so I'd be a bit 
surprised to see the link completely tied up for that long.

I'd suggest you try capturing all outgoing traffic on the link while 
mail is being sent and you're pinging the name server, and see whether 
the data being sent to the server is "clogging" the uplink and 
preventing the pings from getting out in a timely fashion.  (If so, I'm 
not sure why that's happening - the TCP on the mail server probably 
isn't going to be queueing up multiple segments to be sent, so that a 
ping or whatever has to get in line behind several segments, because 
it's not going to be sending segments into a closed window, but maybe 
I'm missing something here.)