Optimalizace TCP protokolu na WAN linkách

[hapi]

to mi vysvětli ty, my jsme na nic nepřišly. Jediná údajná změna nastala když dodavatel vyměnil 13 prvků v cestě za jednu optiku. Ftipný je, že to samí se stalo někomu jinýmu, v jiný části republiky, u jinyho dodavatele, na jiný infrastruktuře. Jediný co pomohlo je totální restruktualizace u dodavatele nebo v druhym případě pouhá změna dodavatele. Čim to bylo skutečně se asi nikdy nedozvíme. Každopádně jedno je jistý, před tim to jelo ok a najednou zvrat a linka nejela a na jendo spojení nedala víc než +- 10Mbit. Takže někdo někde musel něco udělat, něco vyměnit, přenastavit atd.. nicméně to nebyl nic v sítích ISPíků ale dodavatelů.

[sub_zero]

no a pak tu máme levelův problém kde se prostě window size nedařilo zvětšit a na vině byly L2 prvky.. ehm... hromada L2 prvků... velká hromada prvků. Přesněji 13 switchů za sebou v řadě.

No a proč vlastně ty musíš u klientů používat tcp optimizer když ostatní to dělat nemusí? Neni to divný? Vim že máte infrastrukturu hodně pokročilější než my a tyhle problemy nemáme. Navíc naše síť má větší latence než vaše včetně připojení do netu.

Muzes mi prosim vysvetlit, co ma spolecneho L2 prvek s TCP/IP? Pokud se nepletu, tak ty L2 prvky nemaji o nejakem window size ani poneti, prave protoze operuji na 2. vrstve, kdezto TCP/IP zacina na 3.

protoze na L2 prvku dochazi k nejvetsimu zpozdeni. Zkus si treba zmerit zpozdeni pres nejakej L2 switch a srovnej to s nejakym Cisco routerem, kde bude napr. zapnutej CEF (cisco express forwarding).
A ted si takovych L2 switchu naskladej za sebe treba 10 (viz problem levela s CDT)
A co se tyka trasportni vrsty L4, tak prave na ni dochazi k vymene informaci o velikosti Windows size, ACK, korekcich, rozdeleni souboru na pakety atd.
Pokud se mylim, budu rad, kdyz me nekdo opravi

btw, treba takovej Majklik, jakozto hodne znalej prispevovatel by sem k tomu mohl neco napsat

[ocior]

protoze na L2 prvku dochazi k nejvetsimu zpozdeni. Zkus si treba zmerit zpozdeni pres nejakej L2 switch a srovnej to s nejakym Cisco routerem, kde bude napr. zapnutej CEF (cisco express forwarding).

http://www.cisco.com/application/pdf/en ... 91d542.pdf

Mohl bych na oplatku vedet, proc se honite za latenci? A v cem pomuze, ze usetris par mikrosekund na aktivnim prvku, kdyz naberes milisekundy na delce vedeni? Cim ten rozdil v radu mikrosekund meris?

[hapi]

ano, přesně tak. Za latencí nemá smysl se honit když wifina tu latenci podstatně zvětší a problemy na takových sítí nejsou a na L2 gigový prvky to paradoxně rosekaji ale maji podstatně menší latenci. Problem bude jinde.

Nechci zbytečně rejpat ale sub_zero má bezkonkurenční latence oproti nám a nedavno řešil špatný rychlosti na jedno spojení. To je tak trochu k zamyšlení. Kde asi bude problem? To samí level, i přez 13 L2 prvků měl nižší latenci než já ale padal na hubu.

[Walkeer]

protoze na L2 prvku dochazi k nejvetsimu zpozdeni.

Sorry, ale to zni jako fakt nesmysl. Neverim tomu.

Zkus si treba zmerit zpozdeni pres nejakej L2 switch a srovnej to s nejakym Cisco routerem, kde bude napr. zapnutej CEF (cisco express forwarding).

Jakoze switch, kterej ten ethernet ramec (s tim TCP packetem) jenom prijme, precte si cilovou MAC, prohleda hash tabulku a posle to dal, bude pomalejsi nez router, ktery musi udelat minimalne totez (musi prohledat ARP tabulku) + nejaky routing decision + musi snizit TTL + musi prepocitat CRC?

A ted si takovych L2 switchu naskladej za sebe treba 10 (viz problem levela s CDT)

Jedine, co se stane, bude vyssi latence, rychlost to rozhodne ovlivnit nemuze....pokud mam spravne nastavenou window size

A co se tyka trasportni vrsty L4, tak prave na ni dochazi k vymene informaci o velikosti Windows size, ACK, korekcich, rozdeleni souboru na pakety atd.

Ano, prave proto na ni nemuzou mit L2 switche zadny vliv

L2 ethernet prvek si lze predstavit jen jako kus kabelu, ktery navysuje latenci. Nic vic, nic min.

[sub_zero]

Vsak sem psal L2, L4
To, ze podle Tebe L2ka NEMA vliv na zpozdeni vs windows size, tak mi vysvetli nasledujici model.situaci, kterou jsem simulovali..

Virtual Server na win 2008 R2, RAID 6ka, nasdileny nejakej adresar -> switch ProCurve 2510G-48-> switch ProCurve 2510G-48-> switch ProCurve 2510G-48-> switch ProCurve 2510G-48-> ten samej virtual, ale v jinym racku. Linky z vSwicthu byly 1Gbit Full po cele trase.

PROC dosahnu timto zapojenim jen cca 600Mbit, nez kdyz propopojim servery 5m patchordem na primo a dosahnu kolem 950Mbit? Switche byly nastaveny uplne v defaultu, bez VLAN, QoSu, RSTP apod. Rychlost na portech byla v automatice. Latence bez switchu (server-server) 950us, se switchema 1.230ms. A podotykam, ze jsou to L2+ switche...

A pokud se to takto chova v LAN, tak si nedokazu predstavit, jak to musi vypadat v nejaky WAN siti. Treba jsem nezkousel, zda na to maji switche vliv pri rekneme IPsecu ci jinym druhu tunelu.
A ano, spravnou velikosti Windows size se da problem do urcite miry eliminovat...ale, vysvetluj uzivatelum na optice, PROC kdyz maji zaplacenej nejakej psoranej premium ucet treba na RS, dostali novej pocitac za 30 tycek a stahovani jim jeden JEN 15Mbit misto 30Mbit? Reknes jim: Aaaale , mas na hovno TCP WIndows Size.. nainstaluj si TCP optimizer a oprav si to... Kazdej Te posle do prdele.
Myslis, ze treba nejakej velkej ISP, kdyz mu reknes, ze linku nevytizis na JEDNO spojeni, ale na 20 uz jo, se s tim bude nejak zaobirat? Nebude.. prijede s merakem, protlaci tam 512kovy a 1500kovy UDP framy, ty projdou na jednicku a rekne: Sorry, problem na L7 vrstve, opravte si TCP windows scaling, transportni vrstva je v poradku... a co udelas, hm?

Edit: mozna by stalo za hrich zkusit pouzit MPLS /jako akceleraci packetu/, protoze vetsina backbone siti je postavena na MPLS /ale ted varim z vody /
Edit 2: kolik lidi tady takovy testy provadelo v praxi na opravdu rychlych pripojkach? Zda se mi, ze teorie je sice krasna vec, ale praxe je v tomhle bohuzel kruta..

Diky.

[hapi]

shit switche? jinak si to neumim vysvětlit jak by rozdíl 22% v čase udělal paseku 350Mbit když evidentně window size bylo pro ten přenos zvětšený a nebylo tedy použitý statický window size... snížení rychlosti by se tedy v případě dynamickýho window size nemělo projevit nebo aspoň ne tak moc.

Nabízí se další otázka, dělá ten samej problem i FTP přenos? Je typický že microsoft share je tupá služba a s window size moc zacházet neumí. To vidim na naší síti kdy mám k serveru 3 switche a samba jede okolo 30-40MB/s ale FTP jede 100MB/s. Proč tomu tak je? Je to snad i ve schopnostech určitý aplikace jestli dokáže odeslat tak velkej balík dat na jednou? Jestli vůbec je schopná vlastnim komunikačním modelem vycházející ze způsobu vlastní komunikace odeslat tak velkej balík dat bez potvrzení? Dokážu si představit že FTP nachrlý velký balíky dat bez problému (záleží na aplikaci FTP serveru) ale samba kouskovaným přenosem neni schopná sestavit například blok dat o velikosti 16kB bez toho aniž by nedošlo k potvrzení na aplikační vrstvě. Pak jaksi nemůže ani dojít na zvětšení windows size když samotná aplikace (ať už třeba kvůly samotný spolehlivosti samotný služby) prostě vyžaduje potvrzení na aplikační vrstvě po menších blokách. Je vůbec tohle možný? Co vy na to?

[Walkeer]

Vsak sem psal L2, L4
To, ze podle Tebe L2ka NEMA vliv na zpozdeni vs windows size, tak mi vysvetli nasledujici model.situaci, kterou jsem simulovali..

To je nepochodpeni meho prispevku. Na zpozdeni samozrejme vliv L2 prvky maji, to jsem pro jistotu napsal v posledni vete, ale nemuzou mit zadny vliv na windows size, resp. o ni nic nevedi a primo ji nemohou ovlivnit (L2 nerozumi prenasenym datum). Kdyz to reknu trohcu jinak, tak zpomaleni TCP protokolu na L2 prvcich je chyba resp. vlastnost TCP protokolu. Na rychlost UDP by L2 prvky nemeli mit zadny vliv, zkus to schvalne zmerit na tvych serverech.
Obecne vzato, rychlost a latence jsou dve spolu nesouvisejici veliciny. Bohuzel, nektere protokoly je svazuji dohromady, jako napr. TCP.

PROC dosahnu timto zapojenim jen cca 600Mbit, nez kdyz propopojim servery 5m patchordem na primo a dosahnu kolem 950Mbit? Switche byly nastaveny uplne v defaultu, bez VLAN, QoSu, RSTP apod. Rychlost na portech byla v automatice. Latence bez switchu (server-server) 950us, se switchema 1.230ms. A podotykam, ze jsou to L2+ switche...

Ze by spatne nastavena window size? zkus to nastavit rucne (vypnutim dynamickeho nastavovani), melo by to pomoci. Dalsi moznost je, ze to L2+ neni ciste L2 switch a ze tam jeste neco s tema ramcema resi a zpomaluje to.

Edit: mozna by stalo za hrich zkusit pouzit MPLS /jako akceleraci packetu/, protoze vetsina backbone siti je postavena na MPLS /ale ted varim z vody /
Diky.

MPLS, pokud se nepletu, je vpodstate neoc na zpusob routovani ala L2, tedy s packetama se pokud vim vubec nemanipuluje a routuji se pomoci jakychsi virtualnich L2 tunelu nebo cest. Cili, jeslti to chapu dobre, pro ty data se MPLS routery chovaji vpodstate jako L2 prvky. a jsme zase u toho sameho..

[ludvik]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

[sub_zero]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

jsem rád,že se našel někdo, kdo moji "teorii" (v praxi odzkoušenou) potvrdí, či se k ním přikloní.
Flow control jsem psal hned na začátku -> zakázat. Nevidím jedinej důvod to mít na backbone nastavený, když jsou stejně propoje na 1 či více Gbit.

Ad policing.. naše nastavení:

bandwidth 5000000
service-policy input QoS-LM-RATE_MARK-INET-In-500Mb
service-policy output QoS-LM-RATE_MARK-INET-Out-500Mb

xxx.xxxx> traffic-profiling standard-profile show statistics port 1

+---------------------- STANDARD PROFILE TABLE --------------------+
| Port | Profile | Statistics |
| | ID| Name | Type Bytes |
+-------+---+--------------------+---------------------------------+
| 1 |1 |TP-1310 | Accepted 18619867684220 |
| | | | Dropped 0 |
+-------+---+--------------------+---------------------------------+
| 1 |2 |TP-127 | Accepted 85634000 |
| | | | Dropped 0 |
+-------+---+--------------------+---------------------------------+


A i když jsem si zdaleka nesáhnuli na limity, stejně upload korektní nebyl.

Hledáme dále

[hapi]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

chápu že ty switche můžou omezovat na základě RED fronty, tedy extra fronta pro ně použitá jako nejjednoduší omezení rychlosti, nicméne pokud člověk nedosahne na cca 80%, zahazování by nemělo začít.

[Walkeer]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

Takoveho provodera nastesti nemam, moje packety mi provider nezahazuje ani pri plne zatezi tam zadny PL neni, kdyz nepocitam nejaky obcasny na wifinach..

[sub_zero]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

Takoveho provodera nastesti nemam, moje packety mi provider nezahazuje ani pri plne zatezi tam zadny PL neni, kdyz nepocitam nejaky obcasny na wifinach..

a kolik odebiras?

[Walkeer]

Jednu teorii bych měl, resp dvě. Policing a flow-control. Pokud si od někoho koupím 150Mbit, jak mi to dá? Nastaví policer na ciscu. Jak se chová policer? Zahazuje přebytečné pakety. A jak se zachová TCP? Sníží window size a rychlost jde do pryč ... Flow control by se tak sice asi chovat nemělo (alespoň do určité míry), ale výsledek je dle mých zkušeností stejný - dojde k zahození paketů. No a pokud tam je těch switchů po cestě hafo, stoupá pravděpodobnost všeho ... hlavně problémů.

Takoveho provodera nastesti nemam, moje packety mi provider nezahazuje ani pri plne zatezi tam zadny PL neni, kdyz nepocitam nejaky obcasny na wifinach..

a kolik odebiras?

100Mb na jednom miste, 24Mb jinde. Jestli to chapu dobre, tak se vam pri plne zatezi zvysuje PL, ze? Tomu rikam kvalitni internet panecku to bych asi reklamoval..

[sub_zero]

100Mb na jednom miste, 24Mb jinde. Jestli to chapu dobre, tak se vam pri plne zatezi zvysuje PL, ze? Tomu rikam kvalitni internet panecku to bych asi reklamoval..

prosim? o zadnym PL se tu nikdo nebavi.. doporucuju si Ti precist celej tento topic jeste jednou + prilozene linky na externi dokumenty