Gammelt postsystem presser internettet: Kina foreslår at indlægge stopklodser

Torben du forsøger at sælge snakeoil her. Fakta er at P routerne ikke har nogen information tilgængelig der tillader en P router at lave QoS mellem de forskellige tunneller, ud over 3 bits fra TC i MPLS headeren. Men det er det du forsøger bilde os ind.

Det du omtaler er protokollen RSVP som kan styre hvilke tunneller der er plads til på et givent link. Man kan tænke sig at et direkte link, der dog ikke har nok kapacitet, kan få plads til VoIP trafik hvorimod en lavere prioriteret tunnel med best effort internet trafik må rutes ad en omvej. På den måde får VoIP trafikken en lavere latency. Problemet med det der, er at i virkelighedens verden får du virkelig seriøst svært ved at finde et eksempel, hvor denne VoIP trafik rent faktisk har væsentligt lavere latency. Og det skyldes at der er rigeligt med kapacitet, så internettrafikken i praksis tager præcis samme rute som din højt prioriteret VoIP trafik og der bliver i øvrigt ikke droppet nogle pakker undervejs.

Tiden er ved at løbe fra det. Bare i de få år jeg har kørt min internet virksomhed er prisen på 100G faldet til det vi betalte for 10G i starten. Det er langt billigere at designe en backbone uden congestion, end det er at investere i udstyr der kan MPLS-TE. Ja vi har MPLS i vores netværk og det bliver primært brugt til VPLS / L2VPN. Vi har ikke MPLS-TE, dels fordi det ikke vil give os noget og fordi udstyret ikke har tilstrækkelig med support.

Det er det jeg forsøger at kommunikere til dig, at tunneler IKKE er prioriteret i forhold til hinanden ude på transportnetværket. Der er kun de tre bits til QoS. En LSR / P router kan ikke se tunnel prioritet og kan derfor hellere ikke prioritere trafik baseret på det.

QoS er en egenskab ved de data som overføres. Priotering af tunneller er en statisk egenskab som lægges fast når netværket bygges op. Netværkets statiske egenskaber er et resultat af Traffic Engeneering (TE).

Kombinationen af QoS (dvs. hvordan man kan putte QoS information ind i FEC etiketter) og TE, dvs. hvordan netværket er bygget og konfigureret, giver til sammen den trafikprioritereing et MPLS kan give.

Hvis man dykker ned i f.eks. Cisos's MPLS netværk, kan man se hvordan traffic engeneering virker. Se f.eks. følgende Cisco IOS kommandoer:

tunnel mpls traffic-eng priority x y - (som sætter prioriteten mellem forskellige tunneller)

tunnel mpls traffic-eng bandwidth xxxx - (som beskriver hvilken båndbredde der er tilgængelig i en given tunnel)

*tunnel mpls traffic-eng administrative-weight nn * - (som giver brugeren mulighed for at definere sin egen administrative prioritering (kaldet vægt, for at undgå misforståelser) af tunnellen)

*tunnel mpls traffic-eng path-option * - (som knytter andre egenskaber til tunnellen, f.eks. om den kan vælges dynamisk, eller er explicit)

En af de helt grundlæggende ideer i et MPLS netværk er, at man switcher (deraf navnet) datatrafik mellem forskellige tunneller, ud fra et design (dvs. ud fra en traffic engeneering) som formodes at give den bedste ydeevne. Batch trafik og trafik med lav prioritet sendes gennem tunneller med lav TE priority, lav TE bandwidth, lav TE weight, osv.

Jeg har gennem årene traffic engeneered en del MPLS net, og har set hvordan de forskellige metoder, kombinationer af administrativ vægt, båndbredder og prioritet virker på nettets samlede ydeevne. I store netværk som f.eks. dækker Skandinavien, hele Europa eller er verdensomspændende, er tunnelprioritet en væsentlig konfigurationsparameter, som har stor betydning for hvordan netværket performer.

Jeg har desværre set en del eksempler på hvordan udbydere af MPLS netværk sjusker med, eller ikke forstår TE. Når kunderne klager bygger udbyderen typisk mere båndbredde i transportnettet. Når det så viser sig, at det fortsat ikke hjælper, men bare betyder at mere trafik siver over på den nye hurtigere linje, begynder han at kigge alvorligt på TE.

Da tunneller kan prioriteres i forhold til hinanden, kan man dermed prioritere trafik vha. QoS, og det er det TDC gør i sit MPLS net.

Det er det jeg forsøger at kommunikere til dig, at tunneler IKKE er prioriteret i forhold til hinanden ude på transportnetværket. Der er kun de tre bits til QoS. En LSR / P router kan ikke se tunnel prioritet og kan derfor hellere ikke prioritere trafik baseret på det.

Tunnel prioritet er ikke en QoS feature.

De 3 bit i TC (Traffic Class), som også betegnes som QoS, kan også indgå i valget af tunnel. Det kan du se i den wiki du linker til:

"When an unlabeled packet enters the ingress router and needs to be passed on to an MPLS tunnel, the router first determines the forwarding equivalence class (FEC) for the packet and then inserts one or more labels in the packet's newly created MPLS header. The packet is then passed on to the next hop router for this tunnel."

FEC indeholder - eller rettere kan indeholde - QoS parametre. Det kan du se her: https://en.wikipedia.org/wiki/Forwarding_equivalence_class

Det er indholdet af FEC som bestemmer hvilken tunnel der anvendes til næste hop. På den måde kan man koble valget af tunnel med QoS parametren. Valget af tunnel er dermed ikke alene et spørgsmål om nedbrud i netværket, men også af indholdet i FEC og dermed - hvis det ønskes - QoS. Da tunneller kan prioriteres i forhold til hinanden, kan man dermed prioritere trafik vha. QoS, og det er det TDC gør i sit MPLS net.

Nej, det er implementeret med tunnel prioritet. VLAN bruges for at gøre prioriteringen IP-port uafhængig.

Sorry det er noget vrøvl. Tunnel prioritet er ikke en QoS feature. Prøv selv at se på MPLS pakke header formattet:

https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching#Operation

Det eneste en LSR kan lave QoS på er bits 20 til 22 i MPLS headeren. Det er fuldstændig det samme som de tre bits der er i VLAN headeren (vlan priority / PCP / Priority code point). Og kun halvt så meget som de 6 bits der er til rådighed i DSCP / DiffServ feltet i IPv4/IPv6.

Tunnel Prioritet er derimod beregnet til at afgøre hvilke tunneller der skal omdirigeres af alternative veje og hvilke der helt skal droppes i forbindelse med et nedbrud. Du kan eksempelvis sælge til kunden at hans internet muligvis afbrydes men hans VoIP vil forblive ved med at fungere. Det er bare lidt hårdt at sælge til kunderne med en snak om hvordan du agter at lukke ned for hans trafik, så man må kalde det noget andet. Og vi kan formodentlig blive enige om at til dagligt er kundernes trafik ikke afbrudt, hvorfor denne feature absolut intet gør til dagligt. Det er en ting til din SLA.

Sandsynligvis implementeret med DSCP tagging af pakker baseret på vlan hos kunden

Nej, det er implementeret med tunnel prioritet. VLAN bruges for at gøre prioriteringen IP-port uafhængig.

Se f.eks. hvordan TDC gør det: <a href="https://tdc.dk/kundeservice/hjaelp-til-produkt/internet/quality-of-serv…;

Det er meget muligt at de sælger det sammen med et MPLS produkt, men det der er bare old school QoS. Sandsynligvis implementeret med DSCP tagging af pakker baseret på vlan hos kunden. I backbone gør det intet og på lynhurtige moderne linjer minimalt, men det var vigtigt dengang vi kørte på 2 Mbps ADSL og der skulle sikres plads til VoIP.

Masser af viden Jeg ikke havde. Tak for indlægget.
Torben, du burde skrive om v2v comm på denne kanal.

V2V ligger så absolut i udkanten af hvad jeg beskæftiger mig med, og det er bestemt ikke mit speciale.

Når jeg så alligevel våger mig ud i det, er det fordi jeg med en fortid i ETSI, let kan crawle mig igennem det tykke lag af administration som omgiver standarderne, og hurtigt kan få et overblik - som jeg så kan linke videre til. Det er ellers en omstændelig opgave at finde, hvis man ikke kender organisation og administration i disse enorme institutioner.

Min favorit læsning gennem de seneste par år er 5G dvs. 3GPP standarderne. Her hjælper det at kunne sortere, så man bruger læsetiden på det centrale, og sorterer alle de underlige specialting fra, før man mister overblikket. Det er så blevet til nogle små artikler om interessante 5G aspekter på min LinkedIn profil - og der kommer sikkert flere til.

Torben, du burde skrive om v2v comm på denne kanal.

Masser af viden Jeg ikke havde. Tak for indlægget.

Nej, det er et spørgsmål om af den data slet ikke skal på internettet, og det skal bilen designes efter

Hvis man er interesseret i mere information om, hvordan man i de internationale standarder har løst de mange forskellig udfordringer i V2X kommunikation, også f.eks. hvad der skal - og ikke skal - sendes mellem enheder, så der det TS 102 637-2 den ETSI standard man skal have fat i. Den bærer titlen "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service" Den ligger her: https://www.etsi.org/deliver/etsi_ts/102600_102699/10263702/01.02.01_60/ts_10263702v010201p.pdf

Har man brug for "det store overblik" over TS 102, så er indgangen via ETSI:https://www.etsi.org/technologies/automotive-intelligent-transport

Vil man have fat i de tekniske specifikationer (TS) kan man gå ind via ITS kommiteens side:https://www.etsi.org/committee/1402-its

Der er hundredevis af timers interessant læsning hvis man er i det humør.

Det er vel også er spørgsmål om filtrering af data?

Hvordan kan det anvendes til at adskille trafik i trafiktyper og prioritere noget trafik over andet?

Se f.eks. hvordan TDC gør det:https://tdc.dk/kundeservice/hjaelp-til-produkt/internet/quality-of-service

"Kan du blive mere præcis på hvilken feature i MPLS du omtaler her?"</p>
<p>Tunnel prioritet - MPLS TE

Det blev vi ikke klogere af. Tunnel prioritet bruges til at vælge mellem flere alternative tunneller og algoritmen sender 100% af trafikken til den tunnel med lavest prioritet der er aktiv. Hvordan kan det anvendes til at adskille trafik i trafiktyper og prioritere noget trafik over andet?

RSVP https://en.wikipedia.org/wiki/RSVP-TE signalerede TE tunneller kører generelt efter det princip, at enten er der plads til en tunnel eller også er der ikke. Konsekvensen heraf er at hvis der er mangel på kapacitet, så er der nogen der bliver koblet helt af nettet. Og yderligere er konsekvensen at det primært kan benyttes til at give kunderne forskellige SLA, så at der eksempelvis i tilfælde af et fiberbrud og omdirigering af trafikken, så får en erhvervskunde lov til at blive på nettet hvorimod en privatkunde må finde sig i at der er nedetid. Men der er ikke tale om at der i daglig drift er nogen forskel på service til de to typer kunder.

På hvilken måde adskiller det sig fra DSCP / Type of Service feltet fra IPv4?

Du er nødt til at gå ind på NET-2030 fokusgruppen, for at se de mange forskellige forslag der er i spil. Og der er ikke en "ITU idé", der er mange forskellige ideer til hvordan de enkelte bidragsydere forestiller sig at man kan løse problemet. Man er stadigvæk flere år fra at tage beslutninger om løsninger, og endnu længere fra formulering af standarder. Indtil videre er det kun idéer.

Jeg har langt fra læst alle forslag, men af dem jeg har læst, er der ikke rigtigt noget som minder om DSCP. Næsten alle forslag har fat i applikationslagsfunktioner.

ITU NET-2030 kan ses her: https://www.itu.int/en/ITU-T/focusgroups/net2030/Pages/default.aspx

Kan du blive mere præcis på hvilken feature i MPLS du omtaler her?

Ingen i ITU forestiller sig, at det skal være mekanismer som bryder med netneutralitet. Alle behandles ens, men altså med den forskel, at man kan hjælpe sig selv ved at prioritere sin trafik på forhånd.

På hvilken måde adskiller det sig fra DSCP / Type of Service feltet fra IPv4?

https://en.wikipedia.org/wiki/Type_of_service

Man kender princippet i mere simpel form i MPLS, hvor man - via trafiktypen - adskiller højt og lavt prioriteret trafik.

Kan du blive mere præcis på hvilken feature i MPLS du omtaler her? Vores MPLS netværk gør ikke noget i den stil, men hvad ved jeg, vi forsøger også at aflevere 100% af pakkerne.

Det kan lyde besnærende at man kan udnytte kapaciteten bedre, hvis man lige må bryde netneutraliteten.

Helt enig Ole, men det er nu heller ikke de ITU har i tankerne. Nogle af ideerne går på, at du som bruger af transmissionstjenesten, fortæller hvilke dele af din datastrøm ud helst vil undvære - hvis der opstår et kapacitetsproblem.

Man kender princippet i mere simpel form i MPLS, hvor man - via trafiktypen - adskiller højt og lavt prioriteret trafik. Forestillingen er, at man kan udvikle et lignende princip på datastrømme, så man uden at bryde fortrolighed kan stoppe de dele du selv angiver som ikke vigtige.

Om man kan det, og hvordan man gør, er indtil videre ikke afklaret, og det er det ITUs NET-2030 fokusgruppe - sådan lidt forenklet - går ud på.

Det ideelle er naturligvis enten at der er båndbredde nok, eller at man kan acceptere et dyk når der er belastning. Men kan det ikke lade sig gøre, er man nødt til at have nye reguleringsmeaknismer. Ingen i ITU forestiller sig, at det skal være mekanismer som bryder med netneutralitet. Alle behandles ens, men altså med den forskel, at man kan hjælpe sig selv ved at prioritere sin trafik på forhånd.

I det hele taget er det fremtids snak. Der skal laves protokoller til dette, og disse skal godkendes og standardiseres på samme niveau som eks. IpV4 eller 6 er. Dvs internationalt.

Det er korrekt, men fremtidssnak er det ikke. Den første WLAN baserede V2X standard IEEE 802.11p er defineret og vedtaget i 2012. Den understøtter både kommunikation mellem biler (V2V) og mellem bil og infrastruktur (V2I). Man kalder også denne tyde kommunikation for DSRC - Direct Short Range Communication.

Toyota har brugt DSRC siden 2016 - godt nok kun på biler solgt i Japan. I 2017 introducerede GM DSRC på en enkelt modelserie på det amerikanske marked.

3GPP introducerede i 2016 C-V2X, cellular vehicel to "anything", hvor "anything" også er "wide area communication", betegnet N, dvs. C-V2N.

C-V2X er baseret på PC5 interfacet, dvs. det interface man i 5G bruger mellem to UE, og denne type tjeneste betegnes i 5G modellen som en ProSe tjeneste dvs. en Proximity service.

PC5 interfacet har været defineret siden 3GPP release 13, og er således en international standard. I release 13 er det en del af PS-LTE, dvs. Public Safety, og var oprindeligt tænkt til anvendelse af redningsmyndigheder og politi. I 3GPP release 14 er denfintionen af PC5 interfacet udviddet til også at omfatte wearable udstyr, og i C-V2X understøtter PC5 i denne release V2V og V2I.

I 3GPP release 15 (som definerer 5G) er C-V2X med og kaldes for 5G-V2X.

Der er lavet en række undersøgende sammenligninger mellem 5G-V2X og 802.11p som viser, at 5G-V2X på en række punkter er mere velegnet i forhold til at afværge ulykker, primært fordi 5G / PC5 interfacet er i stand til at overføre information med mindre pakketab end 802.11p.

Så de internationale standarder er på plads, og er man interesseret kan man bl.a. læse mere på ETSI EN 302 571: https://www.etsi.org/deliver/etsi_en/302500_302599/302571/02.01.01_60/en_302571v020101p.pdf

10 km væk måske - kan være brugbart ifbm. planlægning af alternative ruter iht. vejarbejde, ulykker etc. Den slags kunne man måske godt sende via internettet - det gør man jo allerede i dag, hvis man har en navigations dims i bilen.

Men data, der direkte har at gøre med bilens styring ift. til andre biler osv. - det er oplagt at angribe det, hvis man vil lave kaos. Det er også en sikkerheds faktor at direkte kommunikation har en geografisk begrænsning. Ingen grund til at man kan fortælle en bil at lyset er grønt I Danmark fra Kina eks.

I det hele taget er det fremtids snak. Der skal laves protokoller til dette, og disse skal godkendes og standardiseres på samme niveau som eks. IpV4 eller 6 er. Dvs internationalt.

Og som med ipv4 og OSI, så kommer der nok også noget VHS vs. Betamax slåskamp før det falder på plads.

Enig.</p>
<p>Men det vil være ekstra unødvendig kompleksitet, at sende sådanne data via internettet.</p>
<p>Bilerne er i sagens natur tæt nok på hinanden og lyskryds til at kommunikere direkte.</p>
<p>At placere biler på internettet mhp at lade den slags data flyde deromkring åbner op for et væld af sikkerheds issues,der er unødvendige.

Det er vel også er spørgsmål om filtrering af data?

Der er ingen grund til at en bil i Jylland skal vide hvad en bil på Sjælland laver.

... eller for den sags skyld blot 10 km væk.

Kort og godt: Hvad er relevant information og hvornår?

Og hvad så med alle de "oldnordiske" biler som kan ikke kommunikere med andre køretøjer?

Så lang tid vi har en blanding af køretøjer på vejen, så synes jeg ærligt talt at det er en noget risikabel affære at automatisere lyskrydset, så man kan køre igennem med 130 km/t uden uheld. :-)

Ja, det er rigtigt, men det udelukker ikke, at biler og robotter godt kan betjene sig at yderligere assistance når den er tilgængelig. På den måde forsker man bl.a. i at lave signalfri vejkryds, hvor biler tilpasser hastigheden så de kan passerer uden at ramme hinanden.

Enig.

Men det vil være ekstra unødvendig kompleksitet, at sende sådanne data via internettet.

1. Bilerne er i sagens natur tæt nok på hinanden og lyskryds til at kommunikere direkte.

2. At placere biler på internettet mhp at lade den slags data flyde deromkring åbner op for et væld af sikkerheds issues,der er unødvendige.

det er årsagen til, at de lynhurtige retransmissioner i dag kører uden om TCP

TCP/IP-modellen er opdelt i 4 lag:</p>
<pre><code>Applikation
Transport,
Internet
Link.

Hvorfor nu lige lave en ny definition, når vi faktisk har OSI's 7lags model at forholde os til.

Vi prøvede fra dansk side at gøre hvad vi kunne for OSI modellen, men 3Com, Novell et al var bare for store.

Det kan lyde besnærende at man kan udnytte kapaciteten bedre, hvis man lige må bryde netneutraliteten.

Men jeg kan godt mærke, at jeg hellere vil leve med mindre båndbredde, hvis det betyder, at ingen kan se, hvad der sker i min krypterede tunnel, og de derfor ikke kan prioritere trafikken baseret på indhold.

Erfaringsmæssigt bliver kapaciteten løbende øget. Det modsatte sker for privatlivsbeskyttelsen.

Jeg vil give ret i at det ikke er meget data, men jeg kan forestille mig meget mere som bilerne kan udveksle. F.eks hastigheder, størrelser og al information de får ind fra diverse kameraer og afstandsmålere, så en bil kan se hvad der sker bag andre biler.

Førerløse fartøjer er tilfældigvis noget jeg har arbejdet med, og jeg må understrege at det vigtigste for alle mobile robotter, uanset om de har passagerer med er latency.

Det er reaktionstiden der er relevant, og ikke så meget båndbredden.

Tænk lige over hvor meget data der skal sendes for at beskrive et lyskryds fuldstændigt for en bil.

Selve lysene tilstande: 2 bit per bane

De andre bilers positioner som GPS 32 bit for hvert hjørne af de andre biler. Så 128 bit per anden bil i krydset.

Derudover en GPS coordinat for hver fodgænger som din egen bil ikke nødvendigvis har set endnu. Måske 2 hvis der er en barnevogn involveret.

Det her kan fint sendes fra bil til bil, helt decentralt med lav latency over diverse sløvere non-web radioer

Det er godt nok ikke meget data..

Men hvordan prioriterer man mellem dit eller mit arbejde eller på tværs af lande?

Simpelt, det gør man ikke. Mit arbejde er præcist så vigtigt som jeg synes det er.

Lav jeres eget autoritært regulerede internet til jeres super vigtige data pakker. Når jeres system bryder sammen pga. politiske uenigheder og ikke kan bruges til at sende jeres vigtige beskeder kan i bide i skeen og bruge det decentrale tcp/ip system.

Det lyder som en meget pæn formulering af "staten skal kunne kontrollere alt kommunikation, og her er endnu en begrundelse" Kina har fået bedre spin doktorer?

Kampen for net neutralitet virker tabt men hvis Kina er mod net neutralitet så er USA jo straks forkæmper. At de så selv har gjort alt de kan for at stoppe det er lige meget. Når KINA gør det må det være ondskaben selv!

Men hvordan prioriterer man mellem dit eller mit arbejde eller på tværs af lande?

Simpelt, det gør man ikke. Mit arbejde er præcist så vigtigt som jeg synes det er. Du har intet at skulle have sagt (ligesom jeg heller ikke har indflydelse på hvordan du bruger nettet). Det skal hverken staten eller ISP pille ved. Om en jurist skal sende en vigtig mail eller et barn skal se tegnefilm, så skal det ene ikke påvirke det andet. Gør det det skal den griske ISP der har oversolgt sin kapacitet hænges ud. En data pakke er en data pakke uanset hvad den indeholder. Er dette ikke godt nok må man lave et parallelt kommunikations medie, ligesom sundhedsvæsenet heller ikke sender organer med Post Nord.

Ja, det er rigtigt, men det udelukker ikke, at biler og robotter godt kan betjene sig at yderligere assistance når den er tilgængelig

En førerløs bil anser jeg som selvkørende, så hvis nettet forsvinder så bør det kun betyde at passergerne ikke mere kan se Netflix, bilen skal kune køre af sig selv uden net

Selvkørende biler skal være det, netop selvkørende, også steder hvor der ikke er nogen internetforbindelse.

Ja, det er rigtigt, men det udelukker ikke, at biler og robotter godt kan betjene sig at yderligere assistance når den er tilgængelig. På den måde forsker man bl.a. i at lave signalfri vejkryds, hvor biler tilpasser hastigheden så de kan passerer uden at ramme hinanden. Det forudsætter information om en mængde forhold, som en autonom enhed ikke selv kan opbygge, og det er her de nye net kommer ind i billedet. Hvor meget sådan en bil så "selv" kører, og hvor meget den hjælpes til selv at køre er et andet spørgsmål. I den branche bruger man derfor også ofte begrebet førerløs.

“ Det dur ikke, hvis du lader software styre din bil eller robotter i industrien,”

Selvkørende biler skal være det, netop selvkørende, også steder hvor der ikke er nogen internetforbindelse.

Hvorfor genopfinde hjulet

IPv6 løser en del af problemet. Det er de store komplekse datastrømme som er vanskelige at have med at gøre. ITU definerer det som Tactile Internet ( Se: https://5g.co.uk/guides/what-is-the-tactile-internet/ ). Problemstillingen går langt ud over både adressering og protokoller.

«Der er åbenlyse begrænsninger i det nuværende internet, fordi mange af de fremtidige applikationer kun fungerer med en kapacitet, der ikke kan opnås med den nuværende IP-protokol. Derfor er vi nødt til at tænke over en ny internet-protokol,« skriver Huawei i deres forslag til en ny IP-protokol.

Neeeej!

Hvorfor genopfinde hjulet?

Der findes allerede en protokol fra 1995, som har ikke kapacitetsproblemer og som er bredt understøttet af diverse enheder.

Det undre mig at Huawei har ikke hørt om den.

Den hedder TCP/IP version 6 (eller blot "ipv6")

I stedet vil Huawei lave en ny protokol, som skal implementeres på alle enheder på hele Internettet.

Vi kan blot kigge på IPv6.

Diverse internetydbydere nøler stadigvæk med last-mile til privatkunder og de har ellers haft 25 år til at blive klar.

Jeg græmmes!

Obligatorisk XKCD tegning

et simpelt transportsystem af små datapakker, der sendes i den rækkefølge de afsendes

Mjah.. Der er vist lidt redundans i den sætning...