Jaderné noviny – 28. 3. 2013: Multipath TCP (diskuse)

[honzulak1]

sed 's/51,8 Mbps/51,8 Gbps/'

[ugh]

Any to nebylo málo

ugh..

[Luboš Doležel (Doli)]

Opraveno.

[Michal Kubeček]

Relace TCP je obvykle navázána pomocí třícestného handshaku.

Obvykle?

[Michal Vyskočil]

Třeba se počítá s TCP_FASTOPEN

[vencour]

Cca před dvěma rokama bylo něco kolem split handshaku ... viz např. tady. To se snad dá počítat jako další možnost ... oboustranné zahájení spojení?

[Honz]

Ten Kim je odkud vlastně...?

[Pali]

Co by sa dalo pouzit na domacu siet, kde pocitac je pripojeny pomocou wifi aj ethernetu aby tcp aj udp spojenie nepadlo po odpojeni wifi resp. eth? Ak by vzialeny server podporoval MTCP, tak by slo prave toto. Chcelo by to nejaky protokol na ktorom by sa router dohodol s pocitacom aby tunelovali komunikaciu aj cez wifi aj eth. Je nieco take?

[pavlix]

Mě už delší dobu láká na tohle použít linuxový bonding/teaming. Ale MTCP by měl zvládat i situace, kdy se nejedná o jedinou síť.

Chcelo by to nejaky protokol na ktorom by sa router dohodol s pocitacom aby tunelovali komunikaciu aj cez wifi aj eth. Je nieco take?

Je toho strašně moc. V podstatě jakýkoli tunel tohle teoreticky dokáže. Ale ty předpokládám hledáš něco zavedeného a jednoduchého a to bude horší.

[Grunt]

Bonding (aspoň ten Linuxový) se týká víceméně jen fyzických rozhraní. I na vlastní síti s podsítěmi je s ním problém. Ochcat to můžeš tunely, ale to také není žádná sláva.

[pavlix]

Bonding (aspoň ten Linuxový) se týká víceméně jen fyzických rozhraní.

Pali psal o wifi a ethernetu. Fyzičtější rozhraní neznám :).

[Pali]

Ano chcelo by to byt nieco pouzivane a nejak funkcne na viacerych systemoch (i ked podporu od windowsu necakam a v podstate ani nepotrebujem). A aj jednoducho konfigurovatelne na roznych linux distribuciach (hotplug asi nepojde, ze?).

[pavlix]

A aj jednoducho konfigurovatelne na roznych linux distribuciach (hotplug asi nepojde, ze?).

Já si osobně myslím, že půjde, jenom ne hned.

[St4nd3l]

Používám takto bonding ale jako active-backup kde má přednost eth před wifi. Když chci rychlost tak pichnu kabel jinak se mohu s NB volně pohybovat.

[pavlix]

Jedna věc je to používat jen pro sebe a když vím, v jakém prostředí se pohybuju a druhá věc je to nabídnout lidem tak, aby to mohli spolehlivě používat bez dalších znalosti. Ale zatím mi přijde že v mé domácí konfiguraci by to mělo taky fungovat v pořádku.

[St4nd3l]

Například PC-BSD takhle nastaví síť po instalaci. Spoji WiFi s ethernetem do lagg (bonding). Pokud se člověk pohybuje tam kde WiFi a ethernet je stejná logická síť tak je to celkem užitečné. Pokud je tomu jinak tak si musí vybrat k čemu chce být připojen.

[pavlix]

Hezké. Nicméně po zkušenostech se síťovými nástroji jsem radši opatrný na cizí tvrzení, že se něco někde běžně používá a vyvozovat z toho, že to funguje správně a bezproblémově.

[Sten]

Na to ani není potřeba bonding, stačí nastavit DHCP server, aby pro WiFi i ethernet na notebooku přiděloval stejnou IP adresu. Je to sice trochu hack, ale ze zkušenosti to funguje spolehlivě.

[pavlix]

Na to ani není potřeba bonding, stačí nastavit DHCP server, aby pro WiFi i ethernet na notebooku přiděloval stejnou IP adresu.

Jednou jsem to chtěl vyzkoušet a ten server tak nastavit nešel (nepamatuju si, co to bylo), protože neumožňoval druhou registraci stejné IP (jinými slovy registraci jedné IP pro dvě MAC).

Další věc je, že svět nekončí u DHCP a IPv4. Takže se opět jedná o řešení do specifických podmínek a ne něco obecného.

[Josef Kufner]

Tohle doma používám, je to velmi praktické a funguje mi to tu už pár let na několika strojích.

Setkal jsem se jen jednou s problémem, kdy nějaký router při takové konfiguraci odmítal komunikovat s druhou použitou síťovkou. Asi šlo o nějakou pseudo-ochranu proti ARP spoofingu.

[Atom321]

A co prostě nastavit oběma síťovkám stejnou IP adresu?

[Pali]

To ma tiez napadlo, ale nesposobi to problemy? A kade pojdu by default packety ked iba pingnem taky pocitac, ktory bude mat aj na wifi aj ethernete rovnaku ip adresu?

[Sten]

Ze zkušenosti chodily po ethernetu

[pavlix]

Že by po eth rychleji doběhla odpověď na ARP dotaz? Tak na tohle bych vůbec nespoléhal. Skoro bych řekl, že tady se člověk musí spálit.

[Josef Kufner]

Ten počítač nesmí mít aktivní obě síťovky současně. To pak dělá bordel.

[pavlix]

Takové věci nemá smysl radit, když to nevyzkoušíš a nenapíšeš k tomu, co to dělalo :).

[Grunt]

Návrháři MPTCP nemají zájem o akademické teoretizování

vs

Prostředníci jsou routery, které na průchozí síťový provoz aplikují nějaká omezení nebo transformace. Jako ukázka mohou posloužit NATy: ukrývají za sebou celou síť za překladovou vrstvou měnící adresu a port spojení při průchodu. NATy mohou do provozu dokonce vkládat data – například přidávat do FTP povely tak, aby fungovalo. Některé krabičky dokonce budou při průchodu potvrzovat data ještě před dosažením skutečného cíle ve snaze zvýšit pipelining. Některé routery zahodí pakety s neznámými volbami; toto chování zbytečně zkomplikovalo nasazení funkce selective acknowledgement (SACK; selektivní potvrzování). Firewally odstřelí spojení s mezerami v sekvenčních číslech; někdy dokonce sekvenční čísla při průchodu transformují. Rozdělení a sloučení segmentů může také způsobut duplikaci nebo zahození voleb. A tak dále; výčet potenciálních problémů je úctyhodný.

Aby to nebylo málo, tak kdokoliv, kdo se bude snažit zavést zcela novou transportní vrstvu, pravděpodobně zjistí, že se Internetem vůbec nerozšíří. Většina směrovací infrastruktury předpokládá, že existuje akorát TCP a UDP; vše ostatní nemá moc šance projít.

Aha. Hmm…

[chrono]

A ďalej sa píše, čo urobili (čo musia urobiť), aby to vyzeralo ako úplne bežné TCP spojenia. ;)

[j]

Sak co se ti na tom nezda - akademici by resili, jak by to melo fungovat na idealni siti = vsichni maji end to end konektivitu = verejne IP adresy. Oni resi aby to fungovalo na siti pekelne rozjebane NATy a dalsim svinstvem ... => popisuji co vsechno je treba brat v uvahu na realne siti.

[dumblob]

No a nebo tady mame Japonce (a par vlastovek jinde po svete), kteri uz par let uspesne testuji a nasazuji (nejen) ve velkych firmach a metropolitnich sitich LISP, coz je protokol z akademickeho prostredi .

[Václav HFechs Švirga]

Grunt tu v posledni dobe akorat troluje , divim se ze ho jeste nekdo bere vazne.

[Grunt]

Ale to ještě přece neznamená, že nemám pravdu, ne?

[Grunt]

Oni resi aby to fungovalo na siti pekelne rozjebane NATy a dalsim svinstvem

No však právě. A to je dle mého názoru chyba. IP(v4) stack na to není stavěný a ohýbat ho donekonečna dle požadavků průmyslu taky nepůjde (a když jo, tak za strašnou cenu – uživatelé NATu by mohli mluvit). Tím nechci říct, že v těch šedesátých letech vymysleli špatnou sadu protokolů, to určitě ne. Spíš naopak, na svou dobu určitě revoluční. Ale s tímhle se prostě v počátcích nepočítalo. Tahle vlastnost je samozřejmě hodně cenná a právě proto mě štve že se to vyvíjí způsobem, je jedno jak, hlavně ať to naroubujeme na stávající infrastrukturu (jako by to měla být poslední věc co schází). Ono kdyby si k tomu sedli ti akademici, tak by se možná zjistilo, že to ani pořádně nemá cenu roubovat. Mnohem radši bych to viděl jako oficiální součást IPv6 nebo protokolů další generace (kompletně splácaných od podlahy).

[j]

Ipv6 je kompletne novej protokol, je tu uz min 15 let ... a ... musim na nej mit tunel, protoze ISP ho stale neumi. Jini zase resi, jak i IPv6 zasrat NATem, jak vyjebat s koncaky a pridelit jim pokud mozno jedinou adresu, ...

[Grunt]

Eyup. Však si to řekněme pěkně plně na rovinu. Celým problémem internetu je internet samotný (resp. jeho uživatelé v kombinaci s těma co zajišťují „infrastrukturu“). Z toho důvodu tu nemáme multicast, nemáme MTCP, nemáme spoustu dalších věcí, Google řeší jak utáhnout gigantické toky u YouTube, vývojáři aplikací jak přechcat NAT a „zajišťovatelé infrastruktury“ jak zajistit infrastrukturu co největšímu počtu lidí s co nejmenšími problémy. A přitom na nějaké RFCčka nebo IETF nebo IPv6 kálí bílý tesák. když to řeknu slušně.

[Heron]

+1

[kralyk z abclinuxu]

zajišťovatelé infrastruktury“ jak zajistit infrastrukturu co největšímu počtu lidí s co nejmenšími problémy

s co nejmenšími problémy náklady

[vencour]

Nooo, když to něco stojí, je to problém. Když se to musí někomu vysvětlovat, je to problém. Když je potřeba udržovat věci v chodu a neměnit je, tak novinka je problém. Tady je slovo problém spíš vyjádřením pocitu ...

[Grunt]

Nooo, když to něco stojí, je to problém.

Když si to někdo neumí udělat, tak je to problém. Nestojí „to“ skoro nic. Stát to začne, až když se na to začne kašlat a nebo když na „to“ nejsou znalosti.

[vencour]

Vona to neni zas taková sranda fungovat v korporátnim prostředí ... dost často se kašle na všechno.

[Grunt]

Až na ty prachy, na ty se najde čas vždycky. Však už taky kolikrát mě napadla idea svobodného meshe místo toho co dneska nazýváme internetem.

[xkucf03]

B.A.T.M.A.N.?

[Grunt]

No, B.A.T.M.A.N.…nikde netvrdím, že to musí být jen bezdrát (já osobně mám celou naši ulic zadrátovanou 1Gbps linkou). Spíš něco jako Freifunk. Tzn. nějaká iniciativa. Problém současného internetu je jeho stromová topologie: Housing → Peering → backbone → ISP → klienti. Dřív internet bývalo nezávislé propojení „amatérských sítí“ (pamatuje ještě někdo IPX/SPX?), dnes je z něj jakýsi „konzumnet“. Taková trošičku interaktivnější televize. Nesymetričnost linek, architektura klient-server namísto peer-peer, naprosto minimální podmnožina podporovaných protokolů (a to mnohdy ještě všelijak okleštěných a furt se možnosti zmenšují), to jsou neduhy které by bylo potřeba do budoucna odstranit. Ach jo. Chtělo by to sednout a sepsat nějaké RFCčko.

[JoHnY2]

A kdyz vsechno selze, tak se nasadi Huhlawei a podobni. Cinan zvladne vsechno, rychle a levne ... kvalita je poznat stejne az po dodani, takze to nikoho mimo techniku netezi, hlavne levne a rychle.

Zase abych jim nekrivdil - nechutne nekvalitni sitovy prvky dokaze vyrobit kde kdo a Huhlaci aspon svoji techniku vylepsujou na zaklade pokusu na zaka... zkusenosti. To docela dost firem ani nedela.

[Grunt]

s co nejmenšími problémy náklady

Co největší počet lidí s co nejmenšími problémy/starostmi, co nejmenšími náklady (čas od času se bije se starostma, protože když padnou na váhu starosti a peníze je jasné co váží víc), za co nejmenší časový úsek (aneb na testování není čas, volte cestu nejmenšího odporu).

[little.owl]

+1

Mam z toho roubovani podobne spatny pocit.

[dumblob]

Ono to je jeste slozitejsi, protoze skupina, ktere za MPTCP stoji z ciste akademickeho prostredi Institute of Information and Communication Technologies, Electronics and Applied Mathematics (ICTEAM).

Konkretne The IP Networking Lab (INL) of the Departement of Computing Science and Engineering at Université catholique de Louvain.

[kralyk z abclinuxu]

..., ale návrh protokolu nasaditelného na dnešním Internetu je překvapivě obtížné.

Cosi divného v téhle větě. s/obtížné/obtížný/ ?

[wert]

http://www.explosm.net/db/files/Comics/Dave/itsnotitsnew.gif

[Bystroushaak]

Related.

[kralyk z abclinuxu]

Tak takhle ohebnou páteř teda nemam

[vencour]

Noo jsem zvědavej na bod 5 RFC 6824, co se z toho stane ... a přitom už teď server se dvěma síťovkama a různýma subnetama přinášel v principu to samé, nutnost mít jistotu, že analyzuju zrovna jeden jedinej fous konektivity.

[dumblob]

Myslim, ze to dobre vystihuje veta ke konci kapitoly 5 v RFC 6824:

For now, the best approach is to get experience with the current approach, establish what might work, and check that the threat analysis is still accurate.