Re: TCP Window Size

On Jun 4, 5:01 pm, Trendkill <jpma...@xxxxxxxxx> wrote:
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.

==================


On Jun 4, 5:01 pm, Trendkill <jpma...@xxxxxxxxx> wrote:
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.

==============================================================

Hi

Thanks again for a very intuition full reply.

"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."

You are absolutely right and this comes with a peculiar blend of
study, experience and psychology


"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"

I got the answer now that it is fine if the Source has a SEND window
size not equal to the DESTINATION RECIEVE Window size.


"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"

I agree with you sir that the application efficiency is the issue here
and it is soaking up most of the bandwidth. On 12Mbps WAN media, a
monthly data PULL is 1 TERA BYTE from one site only. Thanks to NETFLOW
visibility and we are able to thwart the FATA BLOW which could be upon
networking guys from application guys, it is vice versa now.


"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"

I have recently closely observed is that two times in a day when shift
changes, the CEILING effect is seen and all 6 WAN links touch the roof
because of the IIOP application. one number DB queury takes about 1MB
against 4-5 days records but takes 12MB and 59 seconds to 5 minutes to
display against 30 days records.


"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."


WFQ + CEF + per-packet load sharing :-( how does it all works ? I
tried per-destination, but it is not suited at all and few of the 6
WAN links remain chocked while other remain empty. The three terminal
servers along with their clients are placed on the same LAN while then
these TERMINAL SERVERS have java compressed classes based interface
installed for the IIOP application server placed on the other end of 6
pipes. We are pushing the application owners to provide TS on the IIOP
application server LAN.


"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."


I think in per-packet load-balancing with OSPF+CEF, all the packets of
all sessions are thrown out in round robin. A TS session takes 2k per
second per user ?



"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."


I agree with you. Right now the BIG FIGHT is on between teams and I
will let you know the outcome :-)



"You can definitely look into the tcp stuff, but I just don't see it
being your issue based on my experience. "


Right boss

Thanks and Best Regards
Cheema

.

Relevant Pages

  • DAIS 2006 - CALL FOR PARTICIPATION
    ... Distributed Applications and Interoperable Systems ... "From service-oriented architectures ... distribution constellations. ... SESSION 1: ...
    (comp.specification.z)
  • RE: UNC file share and NTLM user identity
    ... Hi Michael, ... |>not developing large-scale internet applications. ... scale-out using NLB can compensate the ... |>session variables purely because of the expensive $ per ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: TCP Window Size
    ... guys and applications guys. ... "Windowing will not help you. ... Yes we have temporary chocking no much how much WAN media is provided ... that your application has 90k to work within per session. ...
    (comp.dcom.sys.cisco)
  • Re: Decimal point or period key brings up Windows Security dialog.
    ... Sometimes there are applications that use hotkeys in a way that causes problems for TS Sessions. ... I've seen some display-driver applications that are client's machine which will cause a key to seem stuck to the system. ... a terminal services session the Windows Security dialog box opens up. ... Additionally when you remote control her session the problem occurs ...
    (microsoft.public.windows.terminal_services)
  • Re: Larrabee details: Yes, it is based on the Pentium. :-)
    ... uplinks and mobile applications. ... codecs ... dejittering etc etc can also be pushed to the network edge. ... All the CPE chipsets handle wide frequency response now. ...
    (comp.arch)
Loading