From: Antonio Soares (amsoares@netcabo.pt)
Date: Fri Jul 06 2007 - 08:26:01 ART
The routers now have support for TCP ECN. Since the theme here is ECN, you
think you may find this interesting:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hiap_c
/ch10/httcpecn.htm
_____
From: darth router [mailto:darklordrouter@gmail.com]
Sent: sexta-feira, 6 de Julho de 2007 2:53
To: Mike Kraus (mikraus)
Cc: Jason Guy (jguy); ccielab@groupstudy.com; Antonio Soares
Subject: Re: ECN with congestion threshold
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
<mailto: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>
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_
<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: <mailto:nobody@groupstudy.com>
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
<mailto: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: <mailto:nobody@groupstudy.com>
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: <mailto:nobody@groupstudy.com>
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
<http://www.groupstudy.com/list/CCIELab.html>
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
<http://www.groupstudy.com/list/CCIELab.html>
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
<http://www.groupstudy.com/list/CCIELab.html>
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART