From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Fri Aug 22 2003 - 13:58:27 GMT-3
Since all we know about this "link" is that it is not congested, how can
we tell if the minimum WRED threshold is ever reached? If it's not
reached then no packets will get dropped by WRED. Even if the minimum
WRED threshold is reached the HTTP and FTP traffic might have the same
IP precedence/DSCP value which would mean that HTTP would get dropped
along with FTP.
No one has brought up the possibility of serialization delay. Maybe
fragmentation of the FTP packets is the solution. The question did say
it was a Frame-Relay link. Maybe the CIR is being exceeded and the
Frame-Relay provider is dropping frames.
In reality there is just too many "maybes" with this question since we
don't know enough about this Frame-Relay link, the LAN, and the users
PC's to determine the real problem of the slow HTTP much less the proper
solution.
Lastly maybe the Internet is slow due to Sobig.F worm ;-)
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Toll Free: 877-334-8987
Direct: 775-745-6404 (Outside the US and Canada)
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
iron_tri
Sent: Friday, August 22, 2003 7:04 AM
To: MMoniz; Brian McGahan; 'Larry Roberts'; 'James Stewart';
ccielab@groupstudy.com
Subject: Re: QoS on Router or Switch
According to a former Campus QoS team member within Cisco, the answer is
WRED. Actually, he wrote the latest QoS design guide, so I am sticking
with
his advice on this one. It is a Congestion Avoidance mechanism. It is
a
quick easy solution that can be enabled with one command, and it can be
modified easily at a later time. It is also best to use WRED when the
majority of traffic is TCP traffic as is the case with this question.
WRED
does not have to detect any type of congestion before it actually takes
effect on a link. Also, there is no mention of any type of traffic that
should receive priority over any other type of traffic in this scenario,
so
WRED is the simple solution.
Good luck.
----- Original Message -----
From: "MMoniz" <ccie2002@tampabay.rr.com>
To: "Brian McGahan" <bmcgahan@internetworkexpert.com>; "'Larry Roberts'"
<larryr@netbeam.net>; "'MMoniz'" <ccie2002@tampabay.rr.com>; "'James
Stewart'" <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
Sent: Wednesday, August 20, 2003 3:37 PM
Subject: RE: QoS on Router or Switch
> That is why I think Web cache would be a better solution. WRED will
only
> come into affect
> in congestion also. This is the type of scenario WCCP was developed
for.
>
> I wouldn't want to rate-limit on uncongested interfaces.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Brian McGahan
> Sent: Wednesday, August 20, 2003 5:20 PM
> To: 'Larry Roberts'; 'MMoniz'; 'James Stewart'; ccielab@groupstudy.com
> Subject: RE: QoS on Router or Switch
>
>
> Larry,
>
> If the link is not congested, then why limit the traffic?
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-334-8987
> Direct: 708-362-1418 (Outside the US and Canada)
>
>
> -----Original Message-----
> From: Larry Roberts [mailto:larryr@netbeam.net]
> Sent: Wednesday, August 20, 2003 4:15 PM
> To: Brian McGahan; 'MMoniz'; 'James Stewart'; ccielab@groupstudy.com
> Subject: Re: QoS on Router or Switch
>
> Brian,
>
> By rate-limiting the FTP traffic, I mean using CAR to limit FTP to say
> 512k.
> This action is in effect even when the link is not congested. I would
> recommend this or WRED as suggested by phong. I wouldn't recommend LLQ
> or PQ
> for web traffic as it is not interactive and doesn't care about
dropped
> packets or delay and jitter.
>
> -Larry
>
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "'Larry Roberts'" <larryr@netbeam.net>; "'MMoniz'"
> <ccie2002@tampabay.rr.com>; "'James Stewart'"
> <j_t_s_stewart@hotmail.com>;
> <ccielab@groupstudy.com>
> Sent: Wednesday, August 20, 2003 2:03 PM
> Subject: RE: QoS on Router or Switch
>
>
> > Larry,
> >
> > Rate-limiting the FTP traffic would not have any effect since
> > the link is not congested. The only QoS mechanism that is
constantly
> in
> > effect even when there is no congestion is the priority queue. The
> > priority queue includes the legacy priority queue, the low latency
> > queue, and RTP.
> >
> > Another consideration when trying to answer this question is the
> > direction of the FTP flow. Are clients receiving the FTP data or
> > sending the FTP data? If we assume that the clients are downloading
> FTP
> > data from the internet, and trying to access web services from the
> > internet, the most effective place to apply a priority queue would
be
> > upstream, which in this case is R2.
> >
> > If you configure a low latency queue to prioritize web replies
> > (source of TCP 80 not destination) from servers on the internet,
this
> > solution should be effective. You could also configure a legacy
> > priority queue on R2, however then you run the risk of completely
> > starving the FTP transfers if web replies are consistently in the
> higher
> > queues.
> >
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-334-8987
> > Direct: 708-362-1418 (Outside the US and Canada)
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Larry Roberts
> > Sent: Wednesday, August 20, 2003 3:43 PM
> > To: MMoniz; James Stewart; ccielab@groupstudy.com
> > Subject: Re: QoS on Router or Switch
> >
> > That is why I recommended rate-limiting the FTP traffic instead. :-)
> >
> > -Larry
> >
> > ----- Original Message -----
> > From: "MMoniz" <ccie2002@tampabay.rr.com>
> > To: "Larry Roberts" <larryr@netbeam.net>; "James Stewart"
> > <j_t_s_stewart@hotmail.com>; <ccielab@groupstudy.com>
> > Sent: Wednesday, August 20, 2003 1:39 PM
> > Subject: RE: QoS on Router or Switch
> >
> >
> > > Jim,
> > >
> > > To me this sounds more like a WCCP solution. Since the link isn't
> > congested
> > > QOS will not really come into play, except of course for like
> > bandwidth
> > > amounts and such.
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
Behalf
> Of
> > > Larry Roberts
> > > Sent: Wednesday, August 20, 2003 3:01 PM
> > > To: James Stewart; ccielab@groupstudy.com
> > > Subject: Re: QoS on Router or Switch
> > >
> > >
> > > James,
> > >
> > > QoS is much easier to implement on a router as opposed to a
switch.
> I
> > would
> > > also look at rate-limiting the FTP traffic so that it can only use
> up
> > a
> > > certain percentage of the bandwidth. Rate-limiting can be done
> either
> > > inbound or outbound on the router, shaping can only be done
> outbound.
> > >
> > > HTH,
> > > Larry Roberts
> > > CCIE #7886 (R&S / Security)
> > >
> > > ----- Original Message -----
> > > From: "James Stewart" <j_t_s_stewart@hotmail.com>
> > > To: <ccielab@groupstudy.com>
> > > Sent: Wednesday, August 20, 2003 11:52 AM
> > > Subject: QoS on Router or Switch
> > >
> > >
> > > > Hi
> > > >
> > > > Not sure where to apply the QoS.
> > > >
> > > > Users on a LAN on R1 complain that www access is slow.
> > > > R1 is connected to the internet via a FR link to R2, which is
not
> > > congested.
> > > > Users on the LAN are also backing up several servers using FTP
> over
> > the
> > > > same link.
> > > >
> > > > Should the QoS giving priority to www over ftp be implemented on
> the
> > 3550
> > > > switch egress port, ingress port of R1 or the egress of R1?
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks Jim
> > > >
> > > >
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:05 GMT-3