Autor: J.F. (jfox_at_priv6.onet.pl)
Data: Thu 12 Aug 1999 - 17:12:50 MET DST
On Wed, 11 Aug 1999 17:01:08 +0200, Pawel Sikora wrote:
>ICMP Source Quench to najstarszy juz mechanizm informowania nadawcy o
>natloku w sieci, bardzo nieprecyzyjny, i nie jest on juz nawet
>rekomendowany (RFC1812) ale i tak jest lepszy niz zaden tj. random drop
>jak to jest obserwowalne na laczach via tpnet.
Ale czy to cokolwiek da ? Bo w tym RFC pisze ze
1) router NIE powinien generowac SQ [bo juz nie zalecamy]
2) router MOZE ignorowac przychodzace SQ
3) proponowano pewne mechanizmy reakcji na otrzymanie SQ, ale
one ciagle nie sa rekomendowane [..i chyba nie beda, bo i SQ
nie jest zalecany]
Jesli koncowe komputery nie zareaguja na SQ - to nie ma sily, tez
trzeba bedzie zgubic pakiety..
>Mozna latwo potestowac roznice pokrewnego zagadnienia
>na takim eksperymentalnym zestawie:
>A.B. koncowi nadawcy/odbiorcy podlaczeni (===) 10 Mbit z routerami
>R1, R2 z uzyciem modemow np. 2Mbit (----):
>
>A===R1--M1-----M2--R2====B
>oraz podobna sytuacje:
>A===R1==B1-----B2==R2====B
>
>gdzie polaczenie jest zrealizowane przez modemy brydzujace B1,B2
>i routery z dwoma ethernetami. Najprosztsze Modemy-brydze B1 i B2
>uwalaja pakiety bez jakiejkolwiek analizy, sa i takie ktore
>analizuja pakiet i generuja kolizje w eth
>Wystarczy zapuscic jednoczesnie kilka wysycajacych lacze sesji ftp
>z A do B zeby zobaczyc jak istotne jest poprawne projektowanie sieci
W obu przypadkach zobaczysz to samo - juz przy jednej sesji praca
innych mocno zwolni [bo czas transmisji przez lacze wydluza sie o
czekajace pare KB w kolejce, przy wiecej - zaczynamy gubic pakiety, i
jest jeszcze gorzej.
Ba - bridge moga miec funkcje "kolidowania" nadchodzacych eternetem
pakietow co spowolni ich wysylanie, routery raczej jej nie beda mialy.
Jeszcze ciekawe moga byc efekty dobierania MTU/MRU - w sieci lokalnej
[a z brydzami to przeciez "lokalna"] raczej nie stosuje sie "large
window", zasadnych do transmisji po WAN :-)
>transmisyjnych narazonych na natlok.
Tylko ze tu zysk by przynioslo:
1) ustawienie priorytetow uslug - ftp, poczta wolno, telnet szybko,
itp - faktycznie, latwiej na routerze, bridge raczej takich
funkcji nie posiadaja.
2) powiekszenie pamieci urzadzen - nie bedzie gubienia tylko
opoznienia
3) dla bridge'y - ograniczenie broadcastow, o ile sa problemem.
Obawiam sie ze zaden SQ nie pomoze, o ile nie zrozumieja go stacje
koncowe.
J.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:23:30 MET DST