Question about interpreting tcptrace results

We have a gigabit network that is sometimes slow, and sometimes not. In
fact, sometimes between the same two endpoints, A->B is fast, while B->A
is slow.

This -might- be related to something that tcptrace is pointing out - that
some of our connections are using RFC 1323 (TCP Window Size Scaling),
while others are not.

Relevant endpoints appear to have RFC 1323 enabled, and inspecting the
first two packets of the TCP negotiation reveal that both want RFC 1323,
but still, tcptrace -sometimes- says we aren't actually getting RFC 1323.

What might cause this?

Is there a way of tracking it down via a series of network commands, or
are we more likely to have to scrutinize each router and switch between
the endpoints?

Thanks!

On Mon, 09 Jan 2006 23:58:15 +0000, Dan Stromberg wrote:

>
> We have a gigabit network that is sometimes slow, and sometimes not. In
> fact, sometimes between the same two endpoints, A->B is fast, while B->A
> is slow.
>
> This -might- be related to something that tcptrace is pointing out - that
> some of our connections are using RFC 1323 (TCP Window Size Scaling),
> while others are not.
>
> Relevant endpoints appear to have RFC 1323 enabled, and inspecting the
> first two packets of the TCP negotiation reveal that both want RFC 1323,
> but still, tcptrace -sometimes- says we aren't actually getting RFC 1323.
>
> What might cause this?
>
> Is there a way of tracking it down via a series of network commands, or
> are we more likely to have to scrutinize each router and switch between
> the endpoints?
>
> Thanks!

This may help someone figure out what the deal is with our sometimes
fast/sometimes slow communications:

http://dcs.nac.uci.edu/~strombrg/opt...dow-table.html

It's a table of host pairs, and whether they got RFC 1323 or not.

Thanks!

Dan Stromberg wrote:
> On Mon, 09 Jan 2006 23:58:15 +0000, Dan Stromberg wrote:
>
> >
> > We have a gigabit network that is sometimes slow, and sometimes not. In
> > fact, sometimes between the same two endpoints, A->B is fast, while B->A
> > is slow.
> >
> > This -might- be related to something that tcptrace is pointing out - that
> > some of our connections are using RFC 1323 (TCP Window Size Scaling),
> > while others are not.
> >
> > Relevant endpoints appear to have RFC 1323 enabled, and inspecting the
> > first two packets of the TCP negotiation reveal that both want RFC 1323,
> > but still, tcptrace -sometimes- says we aren't actually getting RFC 1323.
> >
> > What might cause this?
> >
> > Is there a way of tracking it down via a series of network commands, or
> > are we more likely to have to scrutinize each router and switch between
> > the endpoints?
> >
> > Thanks!
>
> This may help someone figure out what the deal is with our sometimes
> fast/sometimes slow communications:
>
> http://dcs.nac.uci.edu/~strombrg/opt...dow-table.html
>
> It's a table of host pairs, and whether they got RFC 1323 or not.

You must have missed my post to your original inquiry about a month
ago. Wondered what happened to you :-)

My post is here:
http://groups.google.com/group/comp....0e07f9a2e9168f

In the interrim I have forgotten just what my doubts were re: your
suggestion that scaling windows _were_ being properly negotiated.
Reading my post refreshes my memory somewhat, but not enough to
pinpoint a specific item -- just the comments in the post. Grrrr [:-(

If you don't drift away this time I will find time to go over your
previous posts in detail again. However, I don't like repeating these
especially thorny sessions, so hopefully you'll return with some
further data. These kinds of problems are _really_ difficult without
access to the network and boxes involved, so you are our eyes into
what's going on. You will have to go beyond what tcptrace can reveal.
Pinpointing the nature/causes of the problem can be a bear.

waiting to hear from ya,
prg

On Mon, 09 Jan 2006 21:10:11 -0800, prg wrote:

>
> Dan Stromberg wrote:
>> On Mon, 09 Jan 2006 23:58:15 +0000, Dan Stromberg wrote:
>>
>> >
>> > We have a gigabit network that is sometimes slow, and sometimes not. In
>> > fact, sometimes between the same two endpoints, A->B is fast, while B->A
>> > is slow.
>> >
>> > This -might- be related to something that tcptrace is pointing out - that
>> > some of our connections are using RFC 1323 (TCP Window Size Scaling),
>> > while others are not.
>> >
>> > Relevant endpoints appear to have RFC 1323 enabled, and inspecting the
>> > first two packets of the TCP negotiation reveal that both want RFC 1323,
>> > but still, tcptrace -sometimes- says we aren't actually getting RFC 1323.
>> >
>> > What might cause this?
>> >
>> > Is there a way of tracking it down via a series of network commands, or
>> > are we more likely to have to scrutinize each router and switch between
>> > the endpoints?
>> >
>> > Thanks!
>>
>> This may help someone figure out what the deal is with our sometimes
>> fast/sometimes slow communications:
>>
>> http://dcs.nac.uci.edu/~strombrg/opt...dow-table.html
>>
>> It's a table of host pairs, and whether they got RFC 1323 or not.
>
> You must have missed my post to your original inquiry about a month
> ago. Wondered what happened to you :-)
>
> My post is here:
> http://groups.google.com/group/comp....0e07f9a2e9168f
>
> In the interrim I have forgotten just what my doubts were re: your
> suggestion that scaling windows _were_ being properly negotiated.
> Reading my post refreshes my memory somewhat, but not enough to
> pinpoint a specific item -- just the comments in the post. Grrrr [:-(
>
> If you don't drift away this time I will find time to go over your
> previous posts in detail again. However, I don't like repeating these
> especially thorny sessions, so hopefully you'll return with some
> further data. These kinds of problems are _really_ difficult without
> access to the network and boxes involved, so you are our eyes into
> what's going on. You will have to go beyond what tcptrace can reveal.
> Pinpointing the nature/causes of the problem can be a bear.
>
> waiting to hear from ya,
> prg

I'm very interested in all this, but:

1) I've had two largish vacations recently

2) The guy who was paying (ESS) for -most- (not all) of my time on this
issue has pulled the plug, so it's only the other, smaller funding source
(NACS) that remains interested in funding my time on this

3) A network guy with the smaller funding source (NACS) is looking at this
lack of RFC 1323 hypothesis to decide if it's worthwhile to put more of my
time into it

I'm going to make sure I read through
http://groups.google.com/group/comp....0e07f9a2e9168f
anyway though, even if I have to do it on my own dime.

Thanks much for your patient assistance!