Ağırlıklı Adil Kuyruk ve Ağırlıklı Rastgele Erken Tespit nasıl ilişkilidir?


10

QoS sistemlerinin nasıl çalıştığını anlamaya çalışıyorum ve WFQ ve WRED'in tam olarak nasıl etkileşime gireceğinden emin değilim.

İlk başta, WFQ'nun bir kuyruk mekanizması olduğunu ve WRED'in bir tıkanıklık önleme mekanizması olduğunu düşündüm. WFQ paketleri kuyruklar halinde zamanlamalı ve WRED kuyruklar dolduğunda bunları bırakmak için oradadır. Örneğin bir L3 anahtarına QoS kurarsam, bir kuyruk mekanizması ve bir tıkanıklık önleme mekanizması kurarım, bu yüzden teorik olarak WFQ ve WRD'nin birlikte çalışmasını sağlayabilirdim. Örneğin, bu belge benim öyle bir şekilde kurulacağımı ima ediyor gibi görünüyor. Diğer bazı Cisco belgeleri bunları bağımsız olarak kullanabileceğimi belirtiyor.

Sonra nasıl çalıştıkları ve İnternet'te arama yapmaya başladıkları hakkında daha fazla bilgi edinmek istedim. Sonuç olarak, şimdi ne olduklarını ve nasıl çalıştıklarını bilmiyorum.

Bazı siteler (en azından içeriği anladığım kadarıyla), paket planlama algoritmalarının ve tıkanıklık önleme algoritmalarının temelde aynı olduğunu iddia ediyor. Örneğin bu Wikipedia makalesinde, hepsi aynı gruba yerleştirilir. Bazı rastgele makaleler WFQ XOR WRED kullanabileceğimi belirtti.

Sormak istediğim şey WFQ ve WRED'in ne kadar ilişkili olduğudur? Ne zaman birini ya da diğerini kullanacağım ve her ikisi de, eğer mümkünse?


1
wfq ve wred aynı İngilizce sözcük kullanımını paylaşmanın ötesinde birbiriyle ilişkisi yok
Mike Pennington

1
"O zaman nasıl çalıştıkları ve İnternet'te arama yapmaya başladıkları hakkında daha fazla bilgi edinmek istedim. Sonuç olarak, şimdi ne olduklarını ve nasıl çalıştıklarını bilmiyorum." Bu QoS'u anlamaya çalıştığım deneyimin% 99,98'ini anlatıyor.
Nanban Jim

Yanıtlar:


10

Ağırlıklı Fair Queuing (WFQ), adın bir kuyruk algoritması anlamına geldiği gibidir. Kuyruk, bir arabirimde tıkanıklık olduğunda kullanılır. Bu genellikle İletim Halkası'nın (TX-Halkası) dolu olduğu tespit edilir. Bu, arayüzün paket göndermekle meşgul olduğu anlamına gelir. Arayüzde tıkanıklık olmadıkça kuyruk oluşmaz. Bazı durumlarda TX halkasının boyutu değiştirilebilir. Küçük bir TX halkası, yazılım kuyruğuna ilk önce hangi paketlerin gönderileceği konusunda daha fazla güç verir, ancak çok etkili değildir. Çok büyük bir TX halkası, yazılım kuyruğunu neredeyse işe yaramaz hale getirir ve önemli paketler için daha yüksek gecikme ve titremeye yol açar.

Varsayılan kuyruk algoritması genellikle İlk Giren İlk Çıkar'dır (FIFO). Bu, paketlerin arayüzün girişine ulaştıklarında tam olarak verildiği anlamına gelir. Bu genellikle arzu edilmez çünkü bazı paketlere öncelik verilmelidir.

Bir müşterinin alt tabakadaki bir İnternet Servis Sağlayıcıdan (İSS) bir hizmet satın alması oldukça yaygındır. Yani, müşteri 50 Mbit / s hizmet satın alıyor ancak fiziksel arayüz 100 Mbit / s hızında çalışıyor. Bu durumda tıkanıklık olmayacak, ancak İSS müşteriden gelen trafik miktarını sınırlayacaktır. Bu durumlarda yapay tıkanıklığı tanıtmak için bir şekillendirici uygulanabilir.

Şimdi tıkanıklık olduğu için bir kuyruk algoritması uygulanabilir. Kuyruk algoritmalarının fazladan bant genişliği sağlamadığını, sadece hangi paketlerin bizim için daha önemli olduğuna karar vermemize izin verdiklerini unutmayın. WFQ, birkaç parametre alan ve buna dayalı bir karar veren bir algoritmadır. Algoritma oldukça karmaşıktır ve ağırlık (IP Önceliği), paket boyutu ve programlama süresini parametre olarak kullanır. Burada INE'den çok detaylı bir açıklama var. WFQ, SSH, Telnet, ses gibi küçük boyutlu akışlara yeterli bant genişliği sağladığından ve dosya aktarımının tüm bant genişliğini çalmayacağı anlamına geldiği için kuyrukla çok fazla uğraşmak istemiyorsa iyi bir seçimdir.

Ağırlıklı Rastgele Erken Teşhis (WRED) bir tıkanıklıktan kaçınma mekanizmasıdır. WRED, Öncelik değerine bağlı olarak kuyrukların boyutunu ölçer ve kuyruk minimum eşik ile maksimum eşik arasında olduğunda paketleri bırakmaya başlar. Yapılandırma her N paketinden 1'inin bırakılmasına karar verecektir. WRED, TCP senkronizasyonunu ve TCP açlığını önlemeye yardımcı olur. TCP paketleri kaybettiğinde yavaş çalışmaya başlar ve tüm TCP oturumları aynı anda paketleri kaybederse senkronize hale gelebilir ve bu da şöyle bir grafik sağlar:

TCP Senkronizasyonu

WRED yapılandırılmamışsa, grafik tam patlama, sonra sessiz, daha sonra tam patlama vb. Gider. WRED daha ortalama bir iletim hızı sağlar. UDP'nin paketleri bırakmadan etkilenmediğini belirtmek önemlidir, çünkü TCP gibi bir onay mekanizması ve sürgülü pencere yoktur. Bu nedenle WRED, SNMP, DNS veya diğer UDP tabanlı protokolleri işleyen bir sınıf gibi UDP tabanlı sınıfa uygulanmamalıdır.

WFQ ve WRED birlikte dağıtılabilir ve dağıtılmalıdır.


2
Merhaba Daniel, güzel cevap. WFQ (WQF değil) olmamalı mı? Ayrıca, WRED'in UDP'ye karşı etkili olmadığını ve UDP Voice gibi UDP tabanlı sınıflarda kullanmaktan kaçınmanız gerektiğini belirtmek gerekir
Mike Pennington

Teşekkürler Mike. WFQ'yu neden yanlış yazdığımdan emin değilim, bunu düzenledim. Ayrıca UDP hakkında kısa bir not aldı. Her zaman harika yayınlar sağlarsınız.
Daniel Dib

8

Her şeyden önce, internette okuduğunuz her şeye inanmayın ;-)

Bazen algoritmalar (veya fiziksel olarak uygulanma şekilleri) teorik bir kategoriye tam olarak uymaz. Dediğiniz şey, ne yaptığını anlamaktan daha az önemlidir.

WFQ'nun (veya başka herhangi bir programlama algoritmasının) tüm noktası, sınırlı akış bant genişliğini çeşitli akışlar arasında paylaşmaktır. WFQ, bant genişliğini her akışa orantılı olarak ayırmaya çalışır. CBWFQ her "sınıf" için aynısını yapar. Sınırsız kuyruklar ve sınırsız hafıza ile mükemmel bir dünyada ihtiyacınız olan tek şey budur - bant genişliğini paylaşırsınız ve herkes mutlu olur.

Ancak cihazların sınırsız kuyruğu ve hafızası olmadığı için bazı "kısayollar" yapılması gerekir. Bir kuyruk sınırlı bir boyuta sahip olduğundan, kuyruğun dolması ve kuyruk düşüşlerine ve trafik senkronizasyonuna neden olma tehlikesi vardır. Esasen, kuyruğum taşmışsa, artık bant genişliğini kontrol etmiyorum.

Kuyruklarımın taşmasını önlemek için Rastgele Erken Algılama kullanıyorum. Bu algoritma, kuyruğun ne kadar dolu olduğuna (derinlik) göre paketleri kuyruktan rasgele düşürür - kuyruk ne kadar doluysa, o kadar çok paket bırakılır. Amaç, zamanlama algoritmasının çalışabilmesi için sıranın taşmasını önlemektir.

Daha sonra bazı parlak Cisco mühendisi, daha az kuyruk (daha basit donanım) kullanabileceğini ve farklı kuyruk derinliklerinde farklı trafik türlerini rastgele düşürebileceğini fark etti. WRED, trafiğin türüne bağlı olarak trafiği kuyruktan farklı derinliklerde bırakır. WRED'i bir tıkanıklık önleme mekanizması olarak adlandırabilseniz de, trafiğin düştüğü derinlik trafik türüne göre değiştiğinden, etki , farklı türlerin kuyrukta daha az alan ve dolayısıyla bant genişliğinden daha az yer almasıdır. Bu yüzden aynı zamanda bir programlama algoritması görevi görür. Sen po-tay-to ve ben de po-tah-toe diyorum.

Bir fark daha: FQ ve WFQ, temel olarak bayt saydıkları için tüm trafik türlerinde çalışır. RED ve WRED sadece TCP ile çalışır, çünkü trafiği yavaşlatmak ve kuyruğun taşmasını önlemek için TCP'nin akış kontrol mekanizmasına bağımlıdırlar.

(Not: Açıklama uğruna, öncelik sıralarını ve LLQ'yu görmezden geliyorum. Bu başka bir cevap).

Mike'ın söylediği her şeye katılıyorum.


1
Mükemmel cevap ve yorum.
generalnetworkerror

-1

İşte CBWFQ ve WRED'in bir örneği:

politika haritası ÇIKIŞ

sınıf Ses
önceliği yüzde 20

sınıf Video
bant genişliği yüzde 30

sınıf P1
bant genişliği yüzde 10
rasgele tespit dscp tabanlı
rasgele tespit dscp af31 26 40 10

sınıf P2
bant genişliği yüzde 15
rastgele algılama dscp tabanlı
rastgele algılama dscp af21 24 40 10

sınıf sınıf varsayılan
Adil kuyruk
rastgele algılama DSCP tabanlı


ne yazık ki bu örnek sorusuna cevap vermiyor. Ne zaman aynı değil
Mike Pennington

Perspektif olarak, bu bir yarış arabası sürücüsüne turboşarj ve dişli oranlarının nasıl ilişkili olduğunu sormak ve bir kelime söylemeden sizi bir yarış pistinde gezdirmek gibi. Etkileşimi (ve / veya eksikliğini) zaten anlıyorsanız, sorun değil ... ama o zaman soruyu sormazdınız.
Nanban Jim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.