Autor: Pawel Sikora (psi_at_polbox.pl)
Data: Wed 11 Aug 1999 - 17:01:08 MET DST
<jh_at_rsi.pl> wrote in message news:7omuq0$2qi$1_at_zeus.polsl.gliwice.pl...
> Pawel Sikora <psi_at_polbox.pl> wrote:
> > W tpnecie zapomnieli co to jest ICMP quench i WFQ, zas
> > w sieci naskowej obslugiwanej przez cisca to dziala
> > a efektem sa stabilne transfery i brak ruchu jalowego
> > jak na laczach tpnetu.
>
> A mozna spytac co to jest i dlaczego tak dobrze robi na stabilnosc
> transferow? I czego brakuje routerom TP SA zeby to obslugiwaly?
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.
Odsylam do bardzo ciekawych ale zapominanych zagadnien tj.
RFC1254 i wlasnie RFC1812, rozdzial Congestion Control.
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
transmisyjnych narazonych na natlok.
Pawel/
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:23:30 MET DST