Thanks for the detailed analysis. The SPAN capture was a good idea, I hadn't thought to do that for some reason. Anyway, disabling the TCP segmentation didn't seem to change anything. I haven't had a chance to look at it yet, but here is the attached SPAN capture.
-----Original Message-----
From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: Tuesday, September 09, 2008 2:48 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] TCP Window Sizes
On Tue, Sep 09, 2008 at 07:31:48PM +0200, Sake Blok wrote:
> On Tue, Sep 09, 2008 at 12:48:59PM -0400, Aaron Allen wrote:
>
> From the pattern of your ack's, it looks like your server has the
> nagle algorythm enabled and the Amazon server has delayed acking
> enabled with a wait time of 100ms. What I think happens is the
> following, but that should be checked with a trace on a spanport
> as tracing on your server will be done *before* the packet is
> segmented by the NIC.
Hmmm... I looked at the trace again and I'm not sure anymore if
it is indeed the nagle-delayed_ack problem. Could you make a
trace like the one you sent, both on the server as on a laptop
attached to a span-port on the switch (with your server port
spanned to it)? I'd like to see the role of the TCP
segmentation offloading on the delays that are visible in your
trace (which seem to be occurring after every 7-8k of data and
slowly increase in delaytime).
Cheers,
Sake
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
https://wireshark.org/mailman/listinfo/wireshark-users
Attachment:
AmazonS3-Span.pcap
Description: AmazonS3-Span.pcap
