[cisco-voip] [OSL | CCIE_Voice] SIlly QoS Question

[Jonathan Charles]

My working assumption is that any lost packets are bad... and only
should be experienced with wireless...

My question was more to my own understanding of CS3 vs. AD31, and why
Cisco would decide to change it to something that appears to have a
higher drop probability...


Jonathan

On Sun, Apr 6, 2008 at 11:04 AM, Peter Smale <psmale at fuse.net> wrote:
> I think there are only 3 drop thresholds on 3550 very primitive RED
>  C1 is better than CS2 which is better than CS3 etc.   But within a class as
>  for as RED or WRED the opposite is true.
>  AD31 is dropped before AF32  etc.   Traffic in CS3 should not be eligible
>  for drop at all.
>  Been a long time since I have taught QoS but that's how I remember it.
>
>  I made the argument sometime ago that control traffic SKINNY RS323 SIP etc.
>  is so negligible that it could just be classified with the RTP stream itself
>  CS2.
>
>  But I guess that would make things too easy.
>
>  By the way if you are dropping packets on a 100 or even 10 meg link in a
>  short Range campus i.e. 10 millisecond range something has gone very wrong.
>  Broadcast storm, virus etc.  in any event you've got a problem to fix.
>  Peter.  :-)
>
>
>
>  -----Original Message-----
>  From: cisco-voip-bounces at puck.nether.net
>  [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jonathan Charles
>  Sent: Saturday, April 05, 2008 5:46 PM
>  To: Pulos, Greg
>  Cc: CCIE Maillist; cisco-voip at puck.nether.net
>  Subject: Re: [cisco-voip] [OSL | CCIE_Voice] SIlly QoS Question
>
>  So, if CS3 has a higher drop probability than AF31, why change the CS3?
>
>  It seems to me that it would be good to get dial-tone when I pick up
>  the receiver, even if there is congestion.
>
>  This seems like a bad idea...
>
>
>
>  Jonathan
>
>  On Sat, Apr 5, 2008 at 6:47 PM, Pulos, Greg <GPulos at doc.gov> wrote:
>  > I think it sounds a bit confusing too but the concept of rfc2474 defining
>  the CSx as 'not subject to dropping' is correct. (although in fact the
>  taildrops can/will drop cs3 if absolutely required by the qos design and
>  traffic requirements.)
>  >
>  >  I think the bigger point that is being made by the migration is to allow
>  for MissionCriticalData to be assigned af31....period. (therefore allowing
>  greater drop preference scalability, ie: AFx(1-3), depending on the qos
>  design and exact traffic type)
>  >
>  >  Gregory T. Pulos II
>  >  Sr. VoIP Engineer
>  >  U.S. Department of Commerce
>  >  Office of the Secretary
>  >  OCIO/ONTO/NOC
>  >  202.482.5010
>  >
>  > gpulos at doc.gov
>  >
>  >  -----Original Message-----
>  >  From: ccie_voice-bounces at onlinestudylist.com
>  [mailto:ccie_voice-bounces at onlinestudylist.com] On Behalf Of Jonathan
>  Charles
>  >  Sent: Saturday, April 05, 2008 6:11 PM
>  >  To: CCIE Maillist; cisco-voip at puck.nether.net
>  >  Subject: [OSL | CCIE_Voice] SIlly QoS Question
>  >
>  >
>  >
>  > [cross-posting to Puck and the CCIE Online Study List...if you guys
>  >  aren't familiar with each other, you should be...]
>  >
>  >
>  >  Ok, so Cisco is migrating control traffic from AF31 to CS3...
>  >
>  >  I am curious as to why... the QoS SRND says they are moving to CS3
>  >  "because Class Selector code points, as defined in RFC 2474, were not
>  >  subject to markdown/aggressive dropping"
>  >
>  >  OK, I guess...
>  >
>  >  But.
>  >
>  >  WRED is enabled on each non-priority queue on the Cisco 3550 (queues
>  >  1,2 and 3)...
>  >
>  >  Doesn't the lack of any drop thresholds (low, medium and high) in the
>  >  CSX PHB levels, cause this traffic to be potentially dumped in the
>  >  case of congestion?
>  >
>  >  In other words, since AF31 has a binary value of 011010 and CS3 has a
>  >  binary value of 011000, that means that CS3 has nothing set for Delay,
>  >  Throughput or Reliability; whereas AF31 had high throughput set.
>  >
>  >  How is CS3 better?
>  >
>  >
>  >
>  >  Jonathan
>  >
>  >
>  _______________________________________________
>  cisco-voip mailing list
>
> cisco-voip at puck.nether.net
>  https://puck.nether.net/mailman/listinfo/cisco-voip
>
>