From: Mike Kraus \(mikraus\) (mikraus@cisco.com)
Date: Thu Jul 05 2007 - 17:13:31 ART
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:39 ART