RE: [cisco-ttl] qos ne zaman devreye girer

From: <gokhan.surucu_at_....>
Date: Tue Mar 28 2006 - 13:58:30 EEST


Selamlar,

Konuyu rezerve etmek ┼čeklinde d├╝┼č├╝n├╝nce biraz kafa kar─▒┼čt─▒r─▒c─▒ olabiliyor san─▒r─▒m.paketleri ├Ânceliklendirirken bw rezerve ediliyor ┼čeklinde de─čilde paketler queue'daki en ├Ân s─▒raya al─▒n─▒yor (dequeueing)diye d├╝┼č├╝nelim.

Ses trafi─či i├žin konu┼čursak ve LLQ yap─▒l─▒p her konu┼čma i├žin kabaca 16K hesap edildigini ve 4 ses konusmas─▒ i├žin LLQ'da ilgili class'a "priority 64" girildi─čini varsayal─▒m.

128K 'l─▒k kiral─▒k hatt─▒m─▒z olsun ve ├╝zerinde hi├ž konu┼čma yok ve 115 K HTTP trafi─či var.

Hi├ž konu┼čma olmad─▒─č─▒nda b├╝t├╝n bandwidth di─čer uygulamalar taraf─▒ndan kullan─▒labilir.

Bu durumda bir tane ses g├Âr├╝┼čmesi ba┼člad─▒─č─▒n─▒ varsayal─▒m.Bu durumda router─▒n yapt─▒─č─▒ ┼čey gelen ses paketlerini queue da ilk s─▒raya atmaktan ba┼čka bir ┼čey de─čil , yoksa X K bw rezerve etmek gibi bir durum cok dogru de─čil.

Bu ┼čekilde ilk konu┼čma devam ederken 3 konusma geldi diyelim bu durumda dequeueing devam eder.Di─čer uygulamalar bu durumda tabii ki paket kay─▒lar─▒na ugrayacakt─▒r.

5 konusma geldi─činde ise "priority 64" komutundaki 64K n─▒n esprisi ortaya c─▒kar.5. konu┼čma ile birlikte priority queue'da kullan─▒lan BW 64K n─▒n ├╝zerine c─▒kaca─č─▒ndan bundan sonra gelen ses paketleri dequeue edilmeyecek ve maalesef b├╝t├╝n ses konu┼čmalar─▒ olumsuz etkilenecektir.

G├Âkhan S├╝r├╝c├╝

-----Original Message-----
From: cisco-ttl@yahoogroups.com [mailto:cisco-ttl@yahoogroups.com] On Behalf Of ext Serdar Kut Sent: Tuesday, March 28, 2006 12:44 PM
To: cisco-ttl@yahoogroups.com
Subject: Re: [cisco-ttl] qos ne zaman devreye girer

tekrar selamlar Devrim abi,    

  senin gibi bir ├╝stadla hatta idol├╝mle irtibat├Ż yakalam├Ż├żken bir k├╝├ž├╝k sorum daha olacak izin verirsen :)    

  rsvp kulland├Ż├░├Żm├Żz durumlarda, ├Ârne├░in bir X uygulamas├Ż icin kaynaktan hedefe bir rezerve konfig├╝rasyonu yap├Żlm├Ż├żsa, bu uygulaman├Żn;    

  1. aktif olmad├Ż├░├Ż dolay├Żs├Żyla pathdeki rezerve edilen kaynaklar├Ż kullanmad├Ż├░├Ż durumlarda, ba├żka herhangi bir Y uygulamas├Ż s├Żk├Ż├żma durumunda bu rezerve edilmi├ż ancak kulan├Żlmayan kaynaktan bandwith alabilir mi? e├░er alabiliyor ise, o anda X uygulamas├Ż devreye girip Y ye ├Âd├╝├ž verilen kayna├░├Ż force ederek tekrar kendi kullan├Żm├Żna ge├žirebilir mi?
  2. X uygulamas├Ż aktifse fakat rezerve edilenden daha az kullan├Żyorsa, rezerve edilmi├ż ancak kullan├Żlmayan k├Żs├Żmdan ba├żka herhangi bir trafik ge├žebilir mi?

  asl├Żnda r&s lab├Żna haz├Żrland├Ż├░├Żm i├žin gerek qos gerekse di├░er konularla ilgili bu tarz sorular kafam├Ż kurcal├Żyor, g├Ân├╝l isterki sizin gibi de├░erli bir expere bu sorular├Ż s├╝rekli sorabileyim ama tabi do├░al olarak bu pek m├╝mk├╝n olam├Żyor. sonu├žta sizin de ├Ânemli g├Ârevleriniz sorumluluklar├Żn├Żz var, cisco.com domaininden mail atabiliyor olmak ├žok kolay olmasa gerek :))    

  ilginiz ve de├░erli a├ž├Żklamalar├Żn├Żz i├žin ├žok ├žok te├żekk├╝rler..    

  iyi ├žal├Ż├żmalar    

  Serdar           

Devrim Yener KUCUK <dkucuk@cisco.com> wrote:   Selam Serdar,

Policing de bir QoS metodudur, haklisin. Dedigin sekilde bir interface'den gececem maksimum trafik miktarini policing ile belirliyebilirsin. Bu anlamda policing'in devreye girmesi icin tabi ki congestion gerekmiyor. Cunku statik bir sekilde, su trafikten fazlasi gecmesin diyorsun.

Benim yazdigim aciklama daha cok Frame-relay QoS icindi. ( cunku en cok karistirilan budur) Ben QoS mailimde, cesitli classlardan olusan, degisik yapidaki trafiklerin, bu classlari hangi sartlarda nasil kullanacagini belirrtim. Yani congestion olmayinca bu butun classlar herhangi baska bir trafik tarafindan kullanilabilir.

Ancak policing de
1- dinamik bir durum soz konusu degil... 2- Normal burst ve extendend burst degerleri , shaping gibi konfigure edilmiyor..

Ornegin: (cok yogun oldugum icin ingilizce gonderiyorum) 1-Modifying the burst and exceed size for the "policer"

Normal burst and extended burst parameter values are diferent in policier (if we compare with the shaper)

For policer:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt4/qcfpolsh.htm#wp1000900

Recommended Burst Values
Cisco recommends the following values for the normal and extended burst parameters:

normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds

extended burst = 2 * normal burst

Ornegin, bu ornekte class-default hic bir zaman 96kyi gecmesin istiyoruz.

policy-map VOICE-128
  class VOICE
    priority 24
  class HIGH
   bandwidth percent 25
  class MGMT
   bandwidth percent 15
   random-detect dscp-based
  class class-default
   fair-queue
   random-detect
     police 96000 18000 36000 conform trans exceed drop <-----

Kisaca cevap vermeye calistim.

Hala net olmayan yer varsa bakalim

Kolay gelsin

Devrim

  selam Devrim abi,     

    verdi├░in ├Ârnekler traffic-shaping ile ilgili ├Ârnekler. peki traffic policing de, ister policy-map'e g├Âm├╝ls├╝n ister interface baz├Żnda yap├Żls├Żn, sonu├žta bir qos metodu de├░il midir? ve bildi├░im kadar├Żyla policing ile bir ├╝st s├Żn├Żr belirleniyor ve s├Żn├Żr├Ż a├żan trafik i├žin bir exceed-action belirleniyor(burst-rate opsiyonu da var yan├Żlm├Żyorsam)..yani congestion olsun yada olmas├Żn, policing ile bir ├╝st limit belirlemi├ż olmuyo muyuz? shaping ile congestion durumunda garanti edilen bir min. bant geni├żli├░i s├Âz konusu iken policing'de durum biraz farkl├Ż de├░il mi?

  Devrim Yener KUCUK <dkucuk@cisco.com> wrote: Selam arkadaslas

  Bu konu ile ilgili cok yanlis anlama oldugu icin detayli bir aciklama   gondermek istedim

  Ornegin %75 kavrami FR icin dogru degil.   FR konfigure edilmisse sadece minCIR'e bakilir   Eger minCIR yoksa, CIR/2 degeri QoS icin kullanilir.   %75 kavrami diger interface tipleri icin gecerlidir ( ATM, ethernet...)   Yani frame-relay interface'de QoS icin hangi deger kullanilir diyorsaniz, bu   deger oncelikle minCIR degeridir...

  Ayrica QoS sadece congestion olunca devreye girer.   Yani congestion olmayinca "priority" yada "bandwidth" ne kullanilirsaniz   kullanin, kullanilmayan bandwidth diger class'lar tarafindan paylasilir.

  Ayrica bu tur QoS uygulamalarinda mutlaka trafik yapisini bilmeniz gerekir.

  Bu konu ile ilgili birkac lab testi yapmistim.   Onu sizinle paylasayim. Ingilizce ama cok basit bir anlatimi oldugu icin   gonderiyorum.

  Kolay gelsin

  Devrim

  To keep in mind in CBWFQ in Frame-relay

  When the bandwidth and priority commands calculate the total amount of   bandwidth available on an entity, the following guidelines are invoked when   the entity is a shaped Frame Relay permanent virtual circuit (PVC):

-If a Minimum Acceptable Committed Information Rate (minCIR) is not
  configured, the CIR is divided by two.
-If a minCIR is configured, the minCIR setting is used in the calculation.
  ( this means the available bandwidth that will be used for the QoS will   mincir value)
-Avoid setting the CIR or minCIR at the access rate. Otherwise, you may see
  output queues building up and causing big delays in CBWFQ classes. The   reason is that the shape rate does not take into account the overhead bytes   of the flag and Cyclic Redundancy Check (CRC) fields, so shaping at line   rate is actually oversubscribing and will cause interface congestion. There   really is no reason to shape at the access rate.   You should always traffic shape at 95 percent of the access rate or, more   generally, the aggregate shaped rate should always be 95 percent below the   access rate.

  For the bandwidth usage:
  http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080   103eae.shtml#howisunusedbandwidthallocated

  "it is important to understand that since the priority classes are policed   during congestion conditions, they are not allocated any remaining bandwidth   from the bandwidth classes. Thus, remaining bandwidth is shared by all   bandwidth classes and class-default. "

  Let us understand the difference of ATM and Frame-relay in CBWFQ:   100 percent, is 75 percent of interface BW in ATM or ethernet.   So for ATM, only 75 percent BW is visible by bandwith and priority command.   This means even if you DONT define a "default-class" the rest of the traffic   will pass during congestion
  For Frame-relay this is NOT true....
  The visible BW for FR is minCIR (for all class include default-class). To   quarantee bandwidth for default-class, bandwidth statement should be put   explicitly under class-default configuration. This means during congestion   if we DONT want any other traffic, we should explicitly define this, like by   permitting any for the default class.

  And the usage of excess bandwidth:
  If excess bandwidth is available, the excess bandwidth is divided amongst   the traffic classes in proportion to their configured bandwidths. If not   all of the bandwidth is allocated, the remaining bandwidth is   proportionally allocated among the classes, based on their configured   bandwidth."

  Let's look at two examples.

  In the first example, policy-map foo guarantees 30 percent of the bandwidth   to class bar and 60 percent of the bandwidth to class baz.

  policy-map foo
    class bar
      bandwidth percent 30
  class baz

     bandwidth percent 60
  Applying this policy to a 1 Mbps link means 300 kbps is guaranteed to class   bar, and 600 kbps is guaranteed to class baz. Importantly, 100 kbps is   leftover for class-default. If class-default DOES NOT need it, the unused   100 kbps is available for use by class bar and class baz. If both classes   need the bandwidth, they share it in proportion to the configured rates. In   this configuration, the sharing ratio is 30:60 or 1:2.

  Second example: ( 4 different classes and 1 class-default)   policy-map Canberra-WAN
    class File-Transfer
     bandwidth percent 10
    class 123
     bandwidth percent 10
    class ftp
     bandwidth percent 10
    class 102
     bandwidth percent 10
    class class-default
     bandwidth percent 55 <===

  What will happen if we explicity define or NOT define "bandwidth percent 55"   in the class-default.
  Let us assume we have only 3 data streams and using 3 classes, first second   and third.

  Answer:

--

  Cisco Teknik Tartisma Listesi (Cisco-ttl)

  Bu listede onerilen degisikliklerin uygulanmasindaki tum sorumluluk   kullaniciya aittir. Liste yoneticileri, oneride bulunan liste uyeleri ya da   bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu tutulamazlar.   Yahoo! Groups Links               



  Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1&cent;/min.

  [Non-text portions of this message have been removed]

--

  Cisco Teknik Tartisma Listesi (Cisco-ttl)

  Bu listede onerilen degisikliklerin uygulanmasindaki tum sorumluluk   kullaniciya aittir. Liste yoneticileri, oneride bulunan liste uyeleri ya da   bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu tutulamazlar.



  YAHOO! GROUPS LINKS     a.. Visit your group "cisco-ttl" on the web.       

    b.. To unsubscribe from this group, send an email to:

     cisco-ttl-unsubscribe@yahoogroups.com
      

    c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


[Non-text portions of this message have been removed]

--
Cisco Teknik Tartisma Listesi (Cisco-ttl)

Bu listede onerilen degisikliklerin uygulanmasindaki tum sorumluluk kullaniciya aittir. Liste yoneticileri, oneride bulunan liste uyeleri ya da bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu tutulamazlar.     



  YAHOO! GROUPS LINKS          Visit your group "cisco-ttl" on the web.     

    To unsubscribe from this group, send an email to:  cisco-ttl-unsubscribe@yahoogroups.com     

    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.     


                   

Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

[Non-text portions of this message have been removed]

--
Cisco Teknik Tartisma Listesi (Cisco-ttl)

Bu listede onerilen degisikliklerin uygulanmasindaki tum sorumluluk kullaniciya aittir. Liste yoneticileri, oneride bulunan liste uyeleri ya da bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu tutulamazlar. Yahoo! Groups Links  

--
Cisco Teknik Tartisma Listesi (Cisco-ttl)

Bu listede onerilen degisikliklerin uygulanmasindaki tum sorumluluk 
kullaniciya aittir. Liste yoneticileri, oneride bulunan liste uyeleri ya da 
bu uyelerin calistigi kuruluslar herhangi bir sekilde sorumlu tutulamazlar. 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cisco-ttl/

<*> To unsubscribe from this group, send an email to:
    cisco-ttl-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 
Received on Tue Mar 28 14:32:00 2006

This archive was generated by hypermail 2.1.8 : Tue Mar 28 2006 - 14:32:00 EEST