From: darth router (darklordrouter@gmail.com)
Date: Thu Jul 05 2007 - 22:52:54 ART
Mike, gotcha, so in FR, its not really doing true ECN. ECN is just
activating the FECN/BECN, and is not comparible to how ECN works on a LAN.
Thanks!
DR
On 7/6/07, Mike Kraus (mikraus) <mikraus@cisco.com> wrote:
>
> Hey Darth,
> The FR commands basically control when a frame switch sends
> BECNs/FECNs. The random-detect ECN command sets the least two significant
> bits of the TOS byte. They do completely different things, once the
> congestion occurs. So, yes, they both send a form of a ECN once congestions
> occurs/bandwidth hits 70%, but you really want to make sure it is the type
> you are intending. Your provided configuration would do nothing in regards
> to Frame BECNs/FECNs, it only adjusts the ECN field.
>
> ------------------------------
> *From:* darth router [mailto:darklordrouter@gmail.com]
> *Sent:* Thursday, July 05, 2007 7:32 PM
> *To:* Mike Kraus (mikraus)
> *Cc:* Jason Guy (jguy); ccielab@groupstudy.com; Antonio Soares
> *Subject:* Re: ECN with congestion threshold
>
> Hey guys,
>
> thanks for all the info. I suppose what I am really after is, do both of
> those commands activate ECN at 70% bandwidth utilization. I know the FR
> command does, but is the bandwidth command sufficient in the MQC version, or
> would I need to shape to 70% instead? The doc CD command ref gives this
> example. I am assuming ECN is activated once the bandwidth hits 70% and
> congestion occurs.
>
> The following example enables ECN in a policy map called "pol1":
>
> Router(config)# *policy-map pol1
> *
>
> Router(config-pmap)# *class class-default
> *
>
> Router(config-pmap)# *bandwidth per 70
> *
>
> Router(config-pmap-c)# *random-detect
> *
>
> Router(config-pmap-c)# *random-detect ecn*
>
>
>
> On 7/6/07, Mike Kraus (mikraus) < mikraus@cisco.com> wrote:
> >
> > Yes, the transport protocol needs to support this and a TCP stack would
> > have to be modified to do so. That is what this RFC is focused on is
> > using these bits for TCP. See section "6. Support from the Transport
> > Protocol" of the RFC.
> >
> > ( http://www.faqs.org/rfcs/rfc3168.html).
> >
> >
> >
> > -----Original Message-----
> > From: Jason Guy (jguy)
> > Sent: Thursday, July 05, 2007 2:33 PM
> > To: Mike Kraus (mikraus); darth router; ccielab@groupstudy.com
> > Cc: Antonio Soares
> > Subject: RE: ECN with congestion threshold
> >
> > Mike,
> >
> > I was confused by the term "TCP ECN" so I did a little digging to figure
> > out what this is. I was thinking the ECN was a bit in the DSCP byte of
> > the IP header. It turns out it is actually 2 most significant bits of
> > the DSCP byte; called the ECT bit and the CE bit.
> >
> > I found this link that explains how IOS uses the ECN field:
> > http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_
> > guide09186a0080087c87.html
> >
> > According to this link it seems WRED just does some extra marking of the
> > packet depending on the thresholds and the queue length. I guess you
> > would need to use some other mechanism on the receiving end to utilize
> > the notification to cause the endpoints to scale back. Does TCP
> > automatically respond to this? Maybe I need to read RFC 3168 and see if
> > it says anything about it. Can anyone clarify this?
> >
> > Thanks,
> > Jason
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf
> > > Of Mike Kraus (mikraus)
> > > Sent: Thursday, July 05, 2007 2:40 PM
> > > To: Mike Kraus (mikraus); darth router; ccielab@groupstudy.com
> > > Cc: Antonio Soares
> > > Subject: RE: ECN with congestion threshold
> > >
> > > As a correction/clarification, Antonio correctly pointed out to me
> > > that the frame-relay congestion commands are intended to be used on
> > > the Frame-Relay DCE side (switch).
> > >
> > > So, assuming you mean to use the TCP ECN capabilities, you need to use
> >
> > > the WRED ECN feature. If you are just looking to control the
> > > FECN/BECN behavior in Frame-Relay, then use the frame-relay congestion
> >
> >
> > > management commands. It's probably inappropriate to compare them in
> > > the way done so below, since you are going to be doing them at
> > > different times for different reasons.
> > >
> > > I apologize for any confusion, and thank Antonio for pointing this
> > out!
> > >
> > > Thanks,
> > > Mike
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto: nobody@groupstudy.com] On Behalf
> > > Of Mike Kraus (mikraus)
> > > Sent: Thursday, July 05, 2007 11:38 AM
> > > To: darth router; ccielab@groupstudy.com
> > > Subject: RE: ECN with congestion threshold
> > >
> > > Note from the command reference:
> > >
> > > The frame-relay congestion threshold ecn command applies only to
> > > default FIFO traffic-shaping queues.
> > >
> > > One ECN threshold applies to all traffic on a traffic-shaping queue.
> >
> > > You cannot configure separate thresholds for committed and excess
> > > traffic.
> > >
> > > However, if you do it at the interface level using frame-relay
> > > congestion-management works differently:
> > >
> > > Frame Relay congestion management is supported only when the
> > > interface is configured with class-based weighted fair queuing (WFQ).
> > >
> > > And, then you can have different threshold for committed and excess:
> > > interface serial1
> > > encapsulation frame-relay
> > > frame-relay congestion-management
> > > threshold ecn be 0
> > > threshold ecn bc 20
> > > threshold de 40
> > >
> > > This is important because:
> > > "When the output interface queue reaches or exceeds the ECN excess
> > > threshold, all Frame Relay DE bit packets on all PVCs crossing that
> > > interface will be marked with FECN or BECN, depending on their
> > > direction of travel. When the queue reaches or exceeds the ECN
> > > committed threshold, all Frame Relay packets will be marked with FECN
> > > or BECN." - Frame Relay Configuration guide.
> > >
> > > Lastly, with random-detect ecn, you are also enabling WRED in the
> > > process, and doesn't really directly relate to DE (unless matching on
> > > fr-de in your class). Not saying this is good/bad, just different.
> > >
> > > So, assuming it doesn't matter what queuing strategy is employed, and
> > > you don't care explicitly about how committed vs. excess/DE traffic is
> >
> > > treated, then yes, I'd say it wouldn't matter.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of darth router
> > > Sent: Thursday, July 05, 2007 6:53 AM
> > > To: ccielab@groupstudy.com
> > > Subject: ECN with congestion threshold
> > >
> > > Do these two commands (FRTS and MQC) behave the same way?
> > >
> > > frame-relay congestion threshold ecn 70
> > >
> > > OR
> > >
> > >
> > > Router(config)# *policy-map pol1*
> > > Router(config-pmap)# *class class-default* Router(config-pmap)#
> > > *bandwidth per 70*
> > > Router(config-pmap-c)# *random-detect*
> > > Router(config-pmap-c)# *random-detect ecn*
> > >
> > >
> > > or would I need to shape on the MQC version to get the desired effect
> > > of using ECN once the bandwidth threshold is hit? I am thinking they
> > > are the same, but just want to make sure.
> > >
> > >
> > > DR
> > >
> > > ______________________________________________________________________
> > > _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > > ______________________________________________________________________
> > > _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > > ______________________________________________________________________
> > > _ Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART