From: Serdar KOYLU (serdar@uludag.org.tr)
Date: Wed 29 Sep 2004 - 16:17:59 EEST
Selamlar..
> Merhaba
> ADSL'de QOS uygulanabilir, uygulasalar cokda guzel bir servis ve katma deger
> getirirdi alternatif olarak standart ADSL servisine, ama malesef ifade
> ettiginiz gibi ADSL paylasilmis ortam mantigi ile hizmet vermeye devam ediyor.
Teorik olarak, QoS her yere uygulanabilir. Ama QoS'un belirli servisler
icin garanti edilmis bant gensilgi saglama olayi ADSL ve Kablo gibi
ortamlarda uygulanmaz. Ornegin FR/SDSL sistemleri tipik ISDN-PRI hatlari
uzerinden saglanir. Burada herbiri 64Kbit/sn olan time slotlari bulunur.
Santraldeki erisim noktasi bu timeslotlardan belli sayida olanini LL
hatta tahsis eder. Birebir n * 64K olarak hat alirsiniz. Bunlarin her
biri de bir 64Kbit ses kanalina tekabul eder.
Sonucta, arada, kullanip kullanmadiginiza bakilmaksizin, sebekeyi
olusturan tum cihazlarin toplam zamanlarinin (TDM icin bu bir telefon
kanalina tekabul eder) belli bir dilimi size tahsis edilmis olur. Bu da
Servisinizin garantisini gosterir, siz her zaman belli timeout zamani
ile karsi uca ulasirsiniz (karsi uc, internet omurgasidir).
Bunun bedelide, surekli bir Telefon kanali (64K Slot) size ayrilmis
seklindedir vede telefon tarifesi ile karsilastirilabilir. Telekom'da
zaten tarifesini standart telefon tarifesi uzerinden duzenler.
Sizin ADSL'e uygulayacaginiz priority seceneklerinin duzgun olabilmesi
icin, belirlenmis bir upload/download hizinin garantilenmis olmasi
gerekir. Yani, sizin yolladiginiz paketlere, bagli oldugunuz router
kendi kuyruk yonetimini uygulamamalidir. Sizden gelenler, her zaman
geldigi sirayla ve bekletmeksizin yoluna devam etmelidir. Ama, DSLAM
cikisi bunu yapabilecek durumda degildir, WFQ gibi adaletli olmaya
calisan bir kuyruk algoritmasi ile calisir ve sizin yazdiginiz QoS
kurallari ezilir gider. Sizde "ohh, ne guzel CBQ ceil/token hesabi
yaptim, ben bir dahiyim neyim" gibisinden kendinizi kandirir gidersiniz.
ADSL WonderScript gibi duzenekler is yapmaz degil. Ama bunlar daha
ziyade celimsiz ADSL modemin kuyruk yukunu yoketmeyi amaclar. Bu sayede,
modem bufferleri daha verimli kullanilir, download hizinizi etkileyen
upload hizi sorunu bir hayli yumusatilir. Kisaca, modeme yollayabilecegi
maximum paketten daha azi yollanir, buda download processing icin modeme
nefes alma imkani tanir. Bilhassa paylasilan baglantilarda bu gercekten
memnun edici neticeler verir. Fakat, ornegin, VPN icin 512K upload'in
256K'sini garantileyeyim diyemezsiniz. Cunku DSLAM cikisinda baska
kurallar uygulanacaktir. Dahasi, UDP/ICMP paketlerine QoS uygulamaya
calismak abesle istigaldir (1). Santraldeki DSLAM kuyruklari bu tur UDP
paketleri (DNS, virusler, SMB vs.) ile sisiyor olacagindan sizin guzelim
TCP (FTP, HTTP, SSH vs) paketlerinin oncelikleri gume gidecektir.
TELCO'lar genellikle downloadlara vs. oncelik tanimayi, boylecede
kullanicilarina bu sorunu hissettirmemeyi yegleyen kuyruk
yapilanmalarina giderler. Buda sizin QoS kurallarinizi altust etmeye
yetiverir.
Saygi ve sevgiler..
----------------
(1) UDP'ye bandwith limiting vs. yapilamaz mi ? Teorik olarak mumkundur
ama, UDP, TCP gibi Slow-start mekanizmasina sahip degildir. UDP paketi
cikar gider. Kuyrukta kalirsa duser. Oysa TCP paketleri icin session
tekrarlanir ve paketi yollayan sahis ACK alabilmek uzere daha dusuk
hizda paket yollar. En garantili bandwith kontrolu, TCP-ACK paketlerini
duzenleyerek yapilabilir. Malum, UDP'de ACK olayi yoktur maalesef.
Sonucta, UDP uzerinde limitleme yapmaya calismak, bilhassa gelen trafik
icin cok zordur. Giden trafik tamam, belki. Fakat, DSLAM'a paket
yollayan tek siz degilsiniz ki ! Sonucta, DSLAM bazi paketleri kuyrukta
oldurur. Bunlar TCP paketiyse, TCP sunuculari hizlarini azaltiverirler,
olur biter (Slow Start). Ama UDP icin gene olanca hizlariyla yuklenmeye
devam ederler. SQL-Slammer vakasinin interneti cokertecek kadar zaiyat
yaratabilmesinin altinda bu UDP'nin kontrol edilemezligi yatar..