From: James Stewart (j_t_s_stewart@hotmail.com)
Date: Fri Aug 22 2003 - 11:34:54 GMT-3
Hi
Many thanks for your input, I think that WRED is the way to go.
Getting it from the horse's mouth, put a lot of importance, particular with
the TCP aspect and that it can modified later.
Cheers
Jim
>From: "iron_tri" <iron_tri@msn.com>
>To: "MMoniz" <ccie2002@tampabay.rr.com>,"Brian McGahan"
><bmcgahan@internetworkexpert.com>,"'Larry Roberts'"
><larryr@netbeam.net>,"'James Stewart'"
><j_t_s_stewart@hotmail.com>,<ccielab@groupstudy.com>
>Subject: Re: QoS on Router or Switch
>Date: Fri, 22 Aug 2003 08:04:08 -0600
>
>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
> > > > >
> > > > > _________________________________________________________________
> > > > > Sign-up for a FREE BT Broadband connection today!
> > > > > http://www.msn.co.uk/specials/btbroadband
> > > > >
> > > > >
> > > > >
> > >
> > _______________________________________________________________________
> > > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion
> > Group.
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > >
> > >
> > _______________________________________________________________________
> > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > > >
> > >
> > _______________________________________________________________________
> > > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > > >
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > _______________________________________________________________________
> > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > _______________________________________________________________________
> > > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> > >
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > _______________________________________________________________________
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > _______________________________________________________________________
> > You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:04 GMT-3