Jaderné noviny – 28. 3. 2013: Multipath TCP

15. 4. 2013 | Luboš Doležel | Jaderné noviny | 4925×

Aktuální verze jádra: 3.9-rc4. Citáty týdne: Paul Moore, Greg Kroah-Hartman, Minchan Kim. Multipath TCP: Jak to funguje; Strach z prostředníků; Výhledy do budoucnosti.

Obsah

• Aktuální verze jádra: 3.9-rc4
• Citáty týdne: Paul Moore, Greg Kroah-Hartman, Minchan Kim
• Multipath TCP
  • Jak to funguje
  • Strach z prostředníků
  • Výhledy do budoucnosti

Aktuální verze jádra: 3.9-rc4

Aktuální vývojová verze jádra je 3.9-rc4 vydaná 23. března. Linus k ní řekl: Další týden, další -rc. A neuklidnilo se to, což znamená, že malé a poklidné -rc2 bylo rozhodně výjimkou... Ačkoliv to nebylo tak klidné, jak bych to rád viděl, nebylo to zase ani tak vzrušující. Většina věci je triviální. Je to všude možně, většina v ovladačích (drm, md, net, mtd, usb, sound), ale něco je i v architekturách (powerpc, arm, sparc, x86) a systémech souborů (cifs, ext4).

Stabilní aktualizace: verze 3.2.42 vyšla 27. března.

Verze 3.8.5, 3.4.38 a 3.0.71 se aktuálně revidují; jejich vydání lze očekávat 28. března nebo později. Revidují se i verze 3.5.7.9 a 3.6.11.1 (nová, krátkodobá řada určená pro podporu realtime stabilních jader na bázi 3.6).

Citáty týdne: Paul Moore, Greg Kroah-Hartman, Minchan Kim

Pozor na to, už jsi nějaké patche do jádra poslal; vytrvej a může se stát, že se jednoho rána probudíš a bude z tebe jaderný vývojář.

-- Paul Moore

Nemůžeš neustále ignorovat patche, to smí jen jaderní vývojáři s většími zkušenostmi :)

-- Greg Kroah-Hartman

Tento patch přidává novou volbu „reclaim pod proc/<pid>/“, aby správce úloh mohl získat paměť jakéhokoliv cílového procesu kdykoliv, odkudkoliv. Mohlo by to platformě dodat další způsob efektivního používání paměti.

Dokáže se to vyhnout zabíjení procesů pro získání volné paměti, což bylo pro mě opravdu hrozné, protože jsem jednou přišel ve hře o nejlepší skóre, co jsem kdy měl, když mi někdo zavolal.

-- Minchan Kim

Multipath TCP

V době návrhu TCP/IP byl svět jednodušší. Síť byla pomalá a primitivní a často byl zázrak, když se ke vzdálenému hostiteli vůbec podařilo navázat spojení. Stroje na obou stranách relace TCP se obvykle nemusely zajímat o to, jak bylo spojení vytvořeno; o tyto podrobnosti se staraly směrovače. Následkem toho je TCP postavené na myšlence (jediného) spojení mezi dvěma hostiteli. Projekt Multipath TCP (MPTCP) se snaží tento pohled na síťování změnit tím, že přidává podporu pro více transportních cest k cílovým bodům; má to mnoho výhod, ale návrh protokolu nasaditelného na dnešním Internetu je překvapivě obtížný.

Všechno se od prvního nasazení TCP docela zkomplikovalo. Připojení do více sítí, které bývalo sférou velkých serverových systémů, je nyní všudypřítomné; chytrý telefon může například mít současně rozhraní pro mobilní síť, Wi-Fi síť a možná i další sítě přes Bluetooth nebo porty USB. Každá z těchto sítí nabízí možnou cestu ke vzdálenému hostiteli, ale jakákoliv relace TCP bude využívat jen jednu z nich. To pochopitelně vede k zavádění pravidel (které rozhraní se má kdy použít) a provozním složitostem: většina uživatelů je například seznámená s tím, že spojení TCP přes Wi-Fi bude přerušeno, jakmile se zařízení přesune mimo dosah přístupového bodu.

Co kdyby relace TCP mohla využívat všechny dostupné cesty mezi oběma stranami? Mělo by to výkonnostní výhody, neboť by každá z cest mohla paralelně přenášet data a přetíženým cestám by šlo se kdykoliv vyhnout ve prospěch rychlejších cest. Také relace by mohly být robustnější. Představte si stream videa, který běží přes mobilní síť i Wi-Fi; pokud divák opustí dům (doufejme, že řídit bude někdo jiný), stream by se bez přerušení transparentně přesunul na mobilní síť. Datová centra, kde jsou vícenásobné cesty mezi systémy a variabilní vytěžování běžné, by takového transportního protokolu také mohla využít.

Problém je v tom, že TCP není navrženo tak, aby takto fungovalo. Vítejte ve světě MPTCP, které tak navrženo je.

Jak to funguje

Relace TCP je obvykle navázána pomocí třícestného handshaku. Hostitel navazující spojení odešle paket s příznakem SYN, přijímající hostitel, pokud je ochoten spojení přijmout, odpoví paketem, který obsahuje příznaky SYN i ACK. Poslední paket ACK odeslaný z navazující strany dostane spojení do stavu „established“; poté je možné data přenášet oběma směry.

Relace MPTCP začíná stejným způsobem s jedním rozdílem: strana, která spojení navazuje, přidá do SYN paketu příznak MP_CAPABLE. Pokud přijímající strana MPTCP také podporuje, tak tento příznak přidá i do odpovědi SYN-ACK; obě strany do těchto paketů přidají kryptografické klíče pro pozdější použití. Poslední ACK (který také musí mít příznak MP_CAPABLE) vytvoří multipath relaci, i když půjde stále o relaci s jedinou cestou, jako je to u tradičního TCP.

Když se používá MPTCP, pak obě strany rozlišují mezi relací jako takovou a konkrétními „podproudy“ používanými v této relaci. Proto může jakákoliv strana navázat další spojení s druhou stranou s tím, že se adresa nebo port na libovolné straně spojení musí lišit. Takže pokud chytrý telefon vytvořil MPTCP spojení k serveru přes rozhraní Wi-Fi:

tak může kdykoliv přidat další podproud tak, že se připojí ke stejnému serveru pomocí svého rozhraní do mobilní sítě:

Podproud je přidán pomocí SYN paketu s volbou MP_JOIN; také obsahuje informace o tom, k jaké relaci MPTCP se má připojit. Tvůrci protokolu mají samozřejmě obavy o to, že by se někdo zákeřný mohl chtít připojit k cizí relaci; tomuto útoku brání kryptografické klíče, které byly předtím vyměněny. Pokud je druhá strana ochotná přidat další podproud, pak povolí navázání nového spojení TCP a přidá jej do relace MPTCP.

Jakmile má relace více než jeden podproud, tak je na každé straně, jak se rozhodne mezi ně provoz dělit (i když je možné označit, aby se používaly konkrétní podproudy, když jiné nefungují). Jediné přijímací okénko se týká celé relace. Každý podproud vypadá jako normální spojení TCP s vlastními sekvenčními čísly, ale relace jako celek má vlastní sekvenční číslo; pro informování druhé strany o složení podproudů do celkového proudu se používá další volba TCP (DSS, neboli „Data Sequence Signal“).

Podproudy v průběhu života spojení MPTCP mohou přibývat i mizet. Mohou být explicitně ukončeny libovolnou stranou nebo mohou zkrátka zmizet, když některá z cest již nebude dostupná. V případě, že všechno pod kapotou funguje správně, pak by si aplikace neměly těchto změn ani všimnout. Podobně jako IP může odstínit změny v routování, MPTCP může ukrýt podrobnosti o tom, jaké cesty se používají. Z pohledu aplikace by to mělo zkrátka fungovat.

Samozřejmě jsme v tomto přehledu přeskočili velké množství detailů. Vytvoření podobného rozšíření protokolu si žádá úvahy o spoustě věcí jako řízení provozu (congestion control), řešení retransmisí přes jiné cesty, řešení toho, jak má jedna strana říci druhé o dostupnosti dalších adres (cest), které lze použít a tak dále. Návrháři MPTCP strávili přemýšlením spoustu času; pro podrobnosti vizte RFC 6824.

Strach z prostředníků

Jeden detail si ale zaslouží pozornost. Návrháři MPTCP nemají zájem o akademické teoretizování; chtějí vytvořit řešení skutečných problémů, které bude nasazeno na stávajícím Internetu. A to znamená, že musí navrhnout něco, co bude na stávající síti fungovat. To znamená, že věci musejí pro existující aplikace fungovat transparentně. Jenže v RFC je celá sekce, která se zabývá „prostředníky“ [middleboxes] a tím, jak mohou sabotovat jakékoliv snahy o zavedení nového protokolu.

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.

Obcházení těchto problémů ovlivňovalo návrh MPTCP na všech úrovních. TCP nebylo pro vícero podproudů nikdy navrženo; než aby se tato myšlenka na protokol dodatečně ohýbala, bylo by možná lepší to předělat od začátku. Bylo by možné se poučit z chyb TCP – někde by možná dávalo smysl udělat věci zcela jinak. Jenže výsledný protokol by na dnešním Internetu nefungoval, proto návrháři neměli na výběr než vytvořit protokol, který z pohledu snad každého prostředníka vypadá jako obyčejné TCP.

Proto je ve všech směrech každý podproud nezávislým spojením TCP. Kvůli tomu, že mezery v sekvenčních číslech mohou způsobovat problémy, každý podproud má vlastní sekvenci a mapování se musí přidávat navrch. Toto mapování používá relativní sekvenční čísla, protože někteří prostředníci mohou při průchodu čísla změnit. Obě strany k adresám svých rozhraní připojují „identifikátory adres“ a při komunikaci o těchto rozhraních je používají, protože adresy jako takové mohly být po cestě změněny NATem. Když jedna strana poví druhé o dostupném rozhraní, přidá „identifikátor adresy“, jenž se bude používat při další komunikaci, neboť NAT mohl viditelnou adresu změnit. Zvlášť pak probíhá kontrola odhalující podproudy, kde dochází k poškozování dat, vkládání předčasných potvrzení nebo odstraňování neznámých voleb; tyto podproudy nebudou použity. A nakonec je to celé navržené tak, že se při příliš silném rušení přejde na obyčejné TCP.

Všechno je to postavené na mazanosti vývojářů MPTCP, ale současně to poukazuje na znepokojující věc: „hloupý“ Internet s transparentním routováním dat je věcí dávné minulosti. To, co máme teď, je nepružná síť, která je k novým technologiím poněkud nepřátelská. Vývojáři MPTCP se tomu dokázali přizpůsobit, ale vyžádalo si to značné úsilí. V budoucnosti se možná přijde na to, že je síť rozbitá natolik zásadním způsobem, že není možné ji opravit; někdo by mohl říci, že obtížnost přechodu na IPv6 je důkazem toho, že k tomu už došlo.

Výhledy do budoucnosti

Současný kód MPTCP je k nalezení v repozitáři MPTCP na githubu; do síťového podstromu jádra přidává dobrých 10 000 řádek. Ačkoliv už byla tato věc zjevně konzultována s různými vývojáři v této oblasti, ještě nebyla zaslána k veřejnému revidování nebo začlenění do hlavní řady jádra. Zjevně to ale funguje: vývojáři MPTCP tvrdí, že se jim podařilo implementovat nejrychlejší existující spojení TCP, kdy rychlost přenosu dosahovala 51,8 Gbps přes šestici 10Gb linek.

MPTCP je stále ještě docela mladé, tudíž se před začleněním nebo produkčním nasazením ještě skoro určitě bude muset udělat docela dost práce. Navíc se musí trochu popřemýšlet o aplikační stránce věci; aplikace, které o MPTCP vědí, by mohly lépe využívat dostupné cesty. Projekty tohoto typu sice nejsou snad nikdy hotové (konec konců doteď ladíme TCP), ale MPTCP se zdá se dostalo do fáze, kdy by s ním mohli uživatelé začít experimentovat.

Zájemci si mohou vzít kód z repozitáře projektu a zkompilovat si vlastní jádro. Těm, kteří se na to necítí, nabízí projekt různé alternativy včetně repozitáře pro Debian, návodu pro nasazení MPTCP na Amazon EC2 a jader pro řadu zařízení s Androidem. Vývojáři samozřejmě rádi uslyší o chybách nebo jiných výsledcích testování.

       

Komentáře

[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.