Hlavní navigace

Vlákno názorů k článku Poslední volný bit IP hlavičky: jak signalizovat zahlcenou linku od Stanislav Schattke - Moc pěkný článek. Díky. Ohledně ECN je to...

  • Článek je starý, nové názory již nelze přidávat.
  • 25. 2. 2020 12:56

    Stanislav Schattke

    Moc pěkný článek. Díky. Ohledně ECN je to někde default povoleno i v odchozím směru? Měl jsem za to, že se ECN moc neujalo.

  • 25. 2. 2020 16:02

    Adam Přibyl

    Implementace existuje jak v Linuxu tak treba pro Cisco, v roce 2018 byl ucinen pokus ECN zapnout v Linuxu jako vychozi ale byla z toho dost katastrofa https://github.com/systemd/systemd/issues/9748
    https://www.bufferbloat.net/projects/ecn-sane/wiki/dtaht_ecn_editorial/
    Idea dobra, ale problem je s tim jak se k tomu chovaji zarizeni, ktera mu nerozumi, predsi jen je to byvale ToS policko v IP headeru rozdelene na DiffServ a ECN...

  • 26. 2. 2020 6:56

    Michal Kubeček

    Problém byl hlavně se zařízeními, jejichž autoři nepochopili, že "must be zero" znamená "sem dávejte nulu, abychom to časem mohli použít pro další rozšíření", a vyložili si to jako "když tu není nula, tak ten paket radši zahoďte". Nemám představu, kolik takhle zmršených zařízení ještě po sítích běhá, ale pokud je jich dost, přesně stejný problém s nimi bude mít jakýkoli nový standard, který ty dva bity bude chtít využít.

  • 26. 2. 2020 10:37

    Miroslav Šilhavý

    Což je ale přesně význam modálního slovesa must. Ve chvíli, kdy není nulový, nutně musím vyvodit, že se jedná o nevalidní packet. Správná formulace by asi byla should be set to zero.

  • 26. 2. 2020 11:58

    Filip Jirsák

    Nikoli. Musíte rozlišovat dvě strany – jedna paket vytváří, druhá ho čte. Na straně vytvářejícího musí být „must“ – ten, kdo paket vytváří tam vždy musí nastavit nulu, nemůže tam někdy dát jedničku, když se rozhodne, že k tomu má dobrý důvod. Povinnost zapisujícího nastavovat tam nulu ale neznamená pro čtecí stranu povinnost kontrolovat, že tam nula je, a dokonce to nedává čtecí straně ani možnost pakety s něčím jiným než nulou zahazovat.

  • 26. 2. 2020 13:20

    Miroslav Šilhavý

    Povinnost zapisujícího nastavovat tam nulu ale neznamená pro čtecí stranu povinnost kontrolovat, že tam nula je, a dokonce to nedává čtecí straně ani možnost pakety s něčím jiným než nulou zahazovat.

    To byste pak nemohl zahazovat žádný packet s nevalidními hlavičkami. Must právě definuje, že druhá strana se na to může spolehnout a smí to kontrolovat (ale nemusí, když nechce).

    Rozhodně snahu detekovat nevalidní packety bych nepovažoval za chybnou. Přečtu si specifikaci a vytvořím si matici flagů, které se smí v kombinací objevit. Cokoliv vím, že se objevit nesmí, můžu vyhodnotit jako nevalidní a naložit s tím podle uvážení (drop, reject, tarpit, forward).

    Rozdíl je tedy ve vyhodnocení: muset / moci / nesmět.
    Pokud flag nesmí nebo musí být nastaven => pak můžu, ale nemusím vyhodnocovat při zpracování
    Jedině pokud flag smí, ale nemusí být nastaven => pak nesmím vyhodnocovat

    26. 2. 2020, 13:20 editováno autorem komentáře

  • 26. 2. 2020 13:43

    Filip Jirsák

    To byste pak nemohl zahazovat žádný packet s nevalidními hlavičkami.
    Ale mohl. Stačí například když je ve specifikaci napsáno, že to je možné kontrolovat a pakety s nevalidními daty je možné zahodit.

    Must právě definuje, že druhá strana se na to může spolehnout
    Právě že ne. Must prostě znamená must, nic jiného.

    Rozhodně snahu detekovat nevalidní packety bych nepovažoval za chybnou.
    O tom se tady ale nebavíme. Tady je záměrně v nějaké verzi specifikace vynechané rezervované místo v paketu pro pozdější využití. A aby bylo možné později ho využít, mají odesílající povinnost tam v této verzi specifikace nastavovat nuly. Příjemce ty vyhrazené bity musí ignorovat. To je princip rezervovaných bitů – příjemce se teď o ně vůbec nezajímá, tím pádem v nich nemůže být nic, co by vyhodnotil jako nevalidní. No a pak se v pozdější verzi specifikace může dát těm rezervovaným bitům význam. Díky tomu, že tam do teď všichni museli nastavovat nulu, je jasné, že nenulovou hodnotu musela nastavit jen implementace, která zná ten nový standard. A díky tomu, že příjemci ta data ignorovali, je jasné, že příjemce, který nezná novou verzi standardu, bude údaje ignorovat, ať budou jakékoli. Teprve příjemce, který novou verzi standardu implementuje, se těmi bity bude zabývat.

    Díky tomu je zajištěno, že se dá postupně přejít na novou verzi standardu – protože proti sobě budou fungovat libovolné dvě kombinace staré × nové. Což je na internetu zásadní, protože tam opravdu není možné říct, že v jeden okamžik všichni najednou začnou používat nový standard.

    Rozdíl je tedy ve vyhodnocení: muset / moci / nesmět.
    Nikoli, rozdíl je ve známém pravidle „buď striktní v tom, co generuješ/odesíláš, ale buď benevolentní v tom, co čteš/přijímáš“.

    Pokud flag nesmí nebo musí být nastaven => pak můžu, ale nemusím vyhodnocovat při zpracování
    Tím byste ovšem úplně zabil koncepci rezervovaných částí struktur. Právě proto existují tyhle případy, kdy jedna strana něco musí udělat, ale druhá se na to nesmí spoléhat. V jedné verzi standardu je to zdánlivě nelogické, ale jakmile začnete uvažovat o tom, že se ten standard v budoucnosti může opravit, objevíte to kouzlo.

  • 26. 2. 2020 14:27

    Miroslav Šilhavý


    Tady je záměrně v nějaké verzi specifikace vynechané rezervované místo v paketu pro pozdější využití. A aby bylo možné později ho využít, mají odesílající povinnost tam v této verzi specifikace nastavovat nuly. Příjemce ty vyhrazené bity musí ignorovat...

    ... V jedné verzi standardu je to zdánlivě nelogické, ale jakmile začnete uvažovat o tom, že se ten standard v budoucnosti může opravit, objevíte to kouzlo.

    Dívejte se na to z druhé strany. Pokud se jedná o rezervovaný bit, tak v době implementace druhá strana nemůže vědět jestli a jak bude bit v praxi zavedený. V budoucnu v něm může být i zásadní hodnota - a úplně stejně by dnes mohl být článek o tom, jak některá zařízení chybně přijímají i packety, které je podle nového standardu potřeba zpracovávat odlišně.

    Je proto naprosto správné, že pokud tady a teď standard ukládá povinnost nastavit bit na nulu, spadá to do kontrol validity na druhé straně.

    To, co popisujete Vy by mělo být popsáno: reserved bit; sending party should set the bit to zero; receiving party must ignore the value. Slovo must je ve standardu uvedeno chybně a nelze to svalovat na ty, co ten standard četli.

  • 26. 2. 2020 14:43

    Filip Jirsák

    V budoucnu v něm může být i zásadní hodnota
    Nemůže. Autoři standardů nejsou magoři.

    Je proto naprosto správné, že pokud tady a teď standard ukládá povinnost nastavit bit na nulu, spadá to do kontrol validity na druhé straně.
    Ne, je to naprosto špatně. Pokud teď standard ukládá povinnost nastavit bit na nulu, neříká to vůbec nic o tom, že se má na druhé straně validovat. A pokud je ten bit výslovně určen jako rezervovaný pro budoucí použití, nesmí ho druhá strana nijak validovat. Ještě jednou – na tomhle je založen princip rezervovaných bitů (nebo jiných rezervovaných částí struktur).

    To, co popisujete Vy by mělo být popsáno: reserved bit; sending party should set the bit to zero; receiving party must ignore the value. Slovo must je ve standardu uvedeno chybně a nelze to svalovat na ty, co ten standard četli.
    Nikoli, už jsem vám to vysvětloval. Aby bylo možné rezervované bity v budoucnosti použít, musí být zajištěno, že tam teď nebude nikdo dávat nic jiného než nuly. Když povolíte vkládat tam cokoli jiného, nemůžete už nikdy v budoucnosti změnit význam těch bitů – protože byste nedokázal rozlišit, zda tam je nenulová hodnota podle starého standardu a někdo prostě jen využil té možnosti nedávat tam nulu, nebo za tam je nenulová hodnota podle nového standardu.

    Možná si zkuste nejdřív nastudovat, co jsou rezervované bity a promyslet si, jak se v budoucnosti začnou používat. Pak nebudete psát takovéhle nesmysly. Chápu, že musíte být v opozici vždy a za každou cenu. Ale je hloupé, když napíšete své „správné“ řešení, které je zjevně nesmyslné a nefunkční.

  • 26. 2. 2020 15:12

    Miroslav Šilhavý

    Ale je hloupé, když napíšete své „správné“ řešení, které je zjevně nesmyslné a nefunkční.

    Chtít, aby autoři standardů klarifikovali texty je hloupé, nesmyslné a nefunkční? Podle mě se oprávněně očekává, že autor textu standardu píše jednoznačně a ve své oblasti by měl být na vyšší úrovni, než ti, kteří standard následují. Variant, jak naformulovat větu správně je víc - zvolili ji nešťastně.

  • 26. 2. 2020 15:44

    Filip Jirsák

    Chtít, aby autoři standardů klarifikovali texty je hloupé, nesmyslné a nefunkční?
    Vy jste chtěl, aby tam místo must bylo should. To je hloupé a bylo by to nefunkční.

    Podle mě se oprávněně očekává, že autor textu standardu píše jednoznačně a ve své oblasti by měl být na vyšší úrovni, než ti, kteří standard následují.
    Nezapomněl jste, že se bavíme o standardu z roku 1980? Ten standard byl zamýšlen pro propojení stovek, možná tisíců zařízení ve specifické sféře. Dnes je o 40 let později, ten standard se používá pro propojení miliard zařízení, streamuje se pomocí něj 4K video, dělají se pomocí něj živé hovory přes celou planetu, řídí se přes něj auta, provádějí operace. Našel byste málo takhle úspěšných standardů.

    Variant, jak naformulovat větu správně je víc - zvolili ji nešťastně.
    Já jsem ale kritizoval to, že váš návrh na „opravu“ je ještě mnohem horší a nefunkční. V tom standardu je napsána ta výše parafrázovaná věta: „In general, an implementation should be conservative
    in its sending behavior, and liberal in its receiving behavior.“ Dále je to rozvedené „should
    accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)“. Ano, mohlo by to to u jednotlivých rezervovaných bitů být explicitně uvedené, že se na přijímající straně má jejich obsah ignorovat. Nicméně žádná jiná interpretace celého standardu stejně není možná, to explicitní uvedení by bylo opravdu jen pro ty, kterým se nechce nad tím ani trošinku přemýšlet a potřebují jen návod, který mohou slepě následovat.

  • 26. 2. 2020 16:51

    Miroslav Šilhavý

    In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.

    Pokud to tam je, pak je to opravdu chyba implementace a beru svá tvrzení zpět.

  • 26. 2. 2020 18:42

    Michal Kubeček

    Ono je tam toho víc. Např. přímo v RFC je mimo jiné přímo nad tabulkou s layoutem napsáno "Bit 6-7: Reserved for Future Use.". A třeba už RFC 1122 (říjen 1989) ty dva nejnižší bity zahrnuje do pole označeného "TOS" (bez bližší specifikace využití).

  • 26. 2. 2020 15:02

    radioing

    Tak především každá slušná norma by měla význam těchto klíčových slov někde v záhlaví definovat, případně se na definice odvolat (třeba na něco jako RFC2119 - https://www.ietf.org/rfc/rfc2119.txt), a poté to ctít. Alespoň v oblastech, kde se pohybuji, tomu tak je. Smutné pak ovšem je, že i přesto existují vykladači norem, kteří význam těchto klíčových slov odvozují z jejich významu v běžné angličtině a nepřistupují k nim "po právnicku". Pokud takový vykladač sedí někde ve vývojovém oddělení firmy, je na problém zaděláno.

  • 26. 2. 2020 21:07

    Miroslav Šilhavý

    Tak především každá slušná norma by měla význam těchto klíčových slov někde v záhlaví definovat, případně se na definice odvolat

    Zrovna to, co je v odkazované RFC2119 je obecně přijímaný výklad a u slova must jsem ještě neviděl jiný. Většinou se vysvětluje právě should [not], kde se určuje, jestli to znamená libovůli (nastavte jak chcete), nebo jestli to znamená že existuje (třeba v jiné normě nebo v jiné části normy) specifikace či výjimka, jak s tím zacházet.

    Samotné slovo must dává jistotu oběma stranám, že se na to mohou spolehnout - to byla první část diskuse s Filipem. Posléze se však vyjasnilo, že v normě je stanoveno, že určuje pravidla pro odeslání packetu strikně, zatímco pro příjem se vyžaduje volnost.

    I v tom pak ale zůstává výkladová nejasnost. Dá se to vykládat tak, že přijímající strana nesmí spoléhat ani na to, co je označeno jako must have. Nebo to může znamenat, že must [not] nepřipouští libovůli ani na jedné straně, zatímco should [not] se má na straně odesílatele vykládat úžeji (striktněji), zatímco na straně příjemce šířeji (méně striktně). Nebo to může i znamenat to, že si má člověk domyslet, že u specifikovaných částí je to rigidní podmínka, zatímco u rezervovaných částí je flexibilní.

    Technicky vzato, must [not] by mělo dávat jistotu oběma stranám. Proti tomu stojí logický argument, že tím pádem by nemohly být rezervované bity nikdy v budoucnu použity, nebo pouze s přijetím faktu, že je potřeba vyměnit zařízení ve chvíli, kdy se stane tato část normy obsoletní.

    26. 2. 2020, 21:09 editováno autorem komentáře