Re: TCP Window Size
- From: Trendkill <jpmason@xxxxxxxxx>
- Date: Mon, 04 Jun 2007 12:01:41 -0000
Hi
Got chance to your valuable comments after weekend.
Good to know that you are a cisco guy. I will put some more cisco
related questions :-)
Can you help me and give some hints how a Networking guy can support
applications on network, is it enough to have solid understanding of
TCP and related mechanisms or there is more required e.g. to
understand how JAVA works or how FTP and/or HTTP works. I am a sniffer
certified and worked for 3 years in Dubai Internet City. I enjoy
supporting these application and like to capture , decode, interpret
and analyze the traffic. I also like all those fights between network
guys and applications guys. I really enjoy when find them miserable
when they have to really look into the applications.
On the other hand, network issues are no less.
"Windowing will not help you. The application will still negotiate,
and if you are max bandwidth, windowing will not allow you to send any
more or less traffic". I fully agree.
One question : do you think it is fine if the source SEND TCP window
size is NOT equal to the destination RECEIVE TCP windows size ? or it
should be same ?
Yes we have temporary chocking no much how much WAN media is provided
and everytime I go in and look at NETFLOW, I find it IIOP application
traffic all over.
As you have mentioned the OPTIONS here
1) move your database
2) increase your WAN
3) decrease your load at any given time
Since another team is involved in DB movement, and they are the DEAF,
THE DUMB THE BLIND, my one year of motivational argument has not born
fruit.
WAN is already running on MAX
for 3rd option, I am trying efforts to off-load traffic after doing
netflow analysis
Qs : Are these t1s bonded together so you have 1 12 meg pipe? While
separate pipes may help separate
users or traffic, 1 12 meg pipe should in theory allow better
communications as the traffic can return at a higher rate. While it
won't do too much when you have your max users like you do now, it may
end up helping a bit
Ans : There are two WAN hops, first hop has 7 E1 links and second hop
has 6 E1 lines with an Ethernet segment in between. There is no MLPPP
or any other kind of bundling. We are using OSPF based load balancing
with CEF and ip load-sharing per-packet command on. All other
applications are working ok
You are right, the CEILING effect is there.
"Maybe you could replicate this database to something local, and allow
your users to hit that? Bottom line is that you will need to get your
business/application resources to help think through options...but it
doesn't sound like something is necessarily 'broken'. "
Very true
And I also agree there isn't something borken here.
Thanks and Best Regards
Cheema
==================================================
A good network resource needs to know how the network runs, how it
should run, and have a very good understanding of the network's
customers. What applications, what are their demands and
requirements, and how they play or don't play with each other. What I
mean by that is in an enterprise network, you have hundred or
thousands of applications. Some are WAN, some are LAN, some are real-
time versus not. Some require large bandwidth and will soak up a
pipe, others are more trickle-feed but may be more open to response
issues because they are chatty.
In your case, I don't mean to tell you ignore TCP, but in my
experience in 2 global fortune 100 companies, I have rarely had to go
down that path. Just because the windows don't match, doesn't mean
that something is wrong. Provided they negotiate, they will negotiate
to the smaller window, and in most thin client applications, the
traffic is so small it isn't reaching peak size anyway. Additionally,
you don't really care about windowing as much as you case about
efficiency of the application in regards to packets. Since you are
seeing a query come in, and 1514 packets return, this should be
efficient as it appears to be asking for bulks of data at once. Too
many times have I seen applications that request 'ok give me the next
cell in the table', and latency/bandwidth will kill you when your
applications are not making efficient DB queries.
In your case, your WAN is definitely utilized, but is not full. 50%
is busy, 70-80% are the beginnings of issues. I mean just as a rough
exercise, each WAN pipe is 50% utilized or 90 of 180k. Yes I know a
t1 is 192, but its generally not realistic given overhead. That means
that your application has 90k to work within per session. Another
issue that you may look into is OSPF load balancing. Generally it is
done per session or per packet, and the default I believe is per
session. If all your users are hitting a single terminal server, I'd
be interested to see if it is actually load balancing the individual
terminal server queries across your multiple pipes, or if it is
considered a separate session. It should be the latter, but
definitely something to watch. Anyway, and back to the point...you
have 90k to share. Yes you may have multiple pipes, but a single
session can only route over one. Which means if you have 30 users, in
theory, 5 are on each of your 6 t1s, sharing 90k, which results in 15k
per session. However bandwidth doesn't necessarily divide, a single
session will probably take everything it can get, and other sessions
will suffer. Even if it is sharing properly, 15k is not a lot if
these queries return a meg or more of data. A 1 meg file at 15k will
take over a minute.
You may want to consider looking at bonding some connections and
inputing some QoS to protect important applications. Generally, any
media stuff like VoIP/Video need to go into a top tier bucket w/ real
time applications close behind (if not in the same bucket), web
applications etc in a third bucket, and ftp/db replication in default.
You can definitely look into the tcp stuff, but I just don't see it
being your issue based on my experience.
.
- Follow-Ups:
- Re: TCP Window Size
- From: Cheema
- Re: TCP Window Size
- References:
- Re: TCP Window Size
- From: Cheema
- Re: TCP Window Size
- From: Trendkill
- Re: TCP Window Size
- From: Cheema
- Re: TCP Window Size
- From: Trendkill
- Re: TCP Window Size
- From: Cheema
- Re: TCP Window Size
- Prev by Date: Re: Question about big Gig E rings
- Next by Date: Re: Certification Question
- Previous by thread: Re: TCP Window Size
- Next by thread: Re: TCP Window Size
- Index(es):
Relevant Pages
|
Loading