Gavin,
that's an interesting question, which I was trying to find answer to
for quite some time :) Per my understanding, the 3550 model was
assigning the egress queue based on the policed-DSCP value. However,
as the 3750/3560 document mentions, this may lead to packet reordering
(actually this is the problem that RSVP/WFQ implementation in IOS was
plagued by) and performance degradation. Thus, per my understanding,
3560 uses the same ingress/egress queue based on the original assigned
QoS value, not the marked down DSCP. This decision might seems to be
ineffective, as all subsequent devices in the network may assign the
packet flows to different queues and reorder them. I never had time to
verify this behavior in practice, which should be doable, by applying
different shaping weights and metering the egress rate for marked down
packets.
HTH
-- Petr Lapukhov, petr_at_INE.com CCIE #16379 (R&S/Security/SP/Voice) Internetwork Expert, Inc. http://www.INE.com Toll Free: 877-224-8987 Outside US: 775-826-4344 2009/10/31 Gavin Schokman <g_schokman_at_yahoo.com.au>: > Hi all, > > Quick one on the policed-dscp map and egress queuing on the 3560. > Second paragraph on page 34-8 of the 3560 documentation finishes by stating > that "marked down packets use the same queues as the original QoS label to > prevent packets in a flow from getting out of order". > Clearly this applies to ingress queuing, but the query I've got is, does > this statement apply to egress queuing as well? > > i.e. is egress queue chosen based on the unmodified internal-DSCP > (calculated at packet ingress), or the modified internal-DSCP (after any > marking has been applied)? > > > Cheers, > Gavin > > > Blogs and organic groups at http://www.ccie.net > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Blogs and organic groups at http://www.ccie.netReceived on Sun Nov 01 2009 - 02:16:17 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:27 ART