Abo
  1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › IETF: Netzwerker wollen Quic-Pakete…

warum kann man die RTT nicht mehr messen?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 21.07.17 - 23:27

    QUIC ist doch nichts weiter als eine Erweiterung für UDP. Demzufolge gibt es immer einen Absender im UDP-Header. Damit ist auch klar, von wo das Paket kommt und man kann entsprechend messen.

    Ich seh gerade das Problem nicht?

  2. Re: warum kann man die RTT nicht mehr messen?

    Autor: v2nc 22.07.17 - 11:01

    Im verlinkten PDF steht man kann nur die RTT vom Handschake messen

  3. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 22.07.17 - 11:09

    Man kann jedes beliebige Paket zu Messen nutzen. Die Frage die sich stellt, warum tun sie es nicht?

    Weil es ist ohne Probleme möglich, nach dem Absenden eines beliebigen UDP-Pakets für ein gewisses Zeitintervall auf ein beliebiges Antwort-Paket zu warten von der Absender-IP. Im statistischen Mittel bekommt man dann mit einer sehr hohen Genauigkeit die reale RTT. Ausreisser hat man auch mit der anderen Variante, eine statistische Mittelung muss so oder so durchgeführt werden.

    Ergo gibt es kein technisches Argument, das gegen die Messung der RTT spricht. Mal ganz davon abgesehen tun dies wenn überhaupt eh nur CDN-Provider. Und die haben noch ganz andere (effektivere) Möglichkeiten.

    Mir dünkt eher, dass es eine hanebüchene Ausrede mit anderem Motiv. Die wollen irgendwas anderes an QUIC nicht haben.

  4. Re: warum kann man die RTT nicht mehr messen?

    Autor: me2 22.07.17 - 19:35

    Poison Nuke schrieb:
    --------------------------------------------------------------------------------
    > Man kann jedes beliebige Paket zu Messen nutzen. Die Frage die sich stellt,
    > warum tun sie es nicht?
    >
    > Weil es ist ohne Probleme möglich, nach dem Absenden eines beliebigen
    > UDP-Pakets für ein gewisses Zeitintervall auf ein beliebiges Antwort-Paket
    > zu warten von der Absender-IP. Im statistischen Mittel bekommt man dann
    > mit einer sehr hohen Genauigkeit die reale RTT. Ausreisser hat man auch mit
    > der anderen Variante, eine statistische Mittelung muss so oder so
    > durchgeführt werden.

    Das ist falsch. UDP hat überhaupt keine Antwortpakete. Wenn du so etwas willst dann musst du in einem auf UDP aufsetzenden Protokoll eine Logik für Antwortpakete haben. Nur diese Logik könntest du nutzen. Die hat QUIC, aber laut Artikel sind die ACKs in QUIC verschlüsselt, das heißt nur der Endpunkt selber könnte sie entschlüsseln und auswerten. Daher am Endpunkt wäre die RTT Information schon da und der Endpunkt könnte seine Senderate und sein Congestion-Window durchaus steuern, wenn ich das richtig verstehe.

    Den Bedenkenträgern geht es aber um die Transportnetze und Verteilungsnetze, die noch gar keine Entschlüsselung vornehmen.


    > Ergo gibt es kein technisches Argument, das gegen die Messung der RTT
    > spricht. Mal ganz davon abgesehen tun dies wenn überhaupt eh nur
    > CDN-Provider. Und die haben noch ganz andere (effektivere) Möglichkeiten.

    Ich frage mich auch: Wenn ein Server-nahes Transportnetz unbedingt die Information über die RTT haben will, gibt es dann nicht eine andere technische Möglichkeit, wie der Server das Netzwerk informieren könnte?

    Welche Probleme hat denn so ein Transportnetz damit, wenn es die Information nicht hat?

  5. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 22.07.17 - 20:21

    me2 schrieb:
    --------------------------------------------------------------------------------
    > Poison Nuke schrieb:
    > ---------------------------------------------------------------------------
    > Das ist falsch. UDP hat überhaupt keine Antwortpakete.

    > Wenn du so etwas willst dann musst du in einem auf UDP
    > aufsetzenden Protokoll eine Logik für Antwortpakete haben.

    ja es war ja auch klar das UDP selbst keine Antwort vorsieht. Aber wie läuft denn eine normale HTTP Kommunikation ab?
    - Anfrage bei Server (GET)
    - Antwort vom Server (200)
    - Anfordern weiterer Ressourcen, weil nie alles im ersten Request übermittelt wird

    Die Zeit zwischen dem ersten HTTP200 und den folgenden Requests ist die RTT. Ob da jetzt wirklich ein 200 oder ein GET oder was auch immer drinsteht ist egal. Es ist allein schon durch die zeitliche Abfolge der Pakete erkennbar, die Muster sind immer gleich und lassen sich leicht in einem ASIC implementieren.

    Damit stehen den CDN Providern genug Möglichkeiten Bereit, die reale RTT zu bestimmen ohne das weitere Informationen der Pakete selbst benötigt werden.

  6. Re: warum kann man die RTT nicht mehr messen?

    Autor: Am.... 22.07.17 - 21:44

    Du verstehst da was falsch... HTTP beruht auf TCP! dort gibt es ACK meldungen.
    Du bist gedanklich ein OSI Layer zu hoch :)



    1 mal bearbeitet, zuletzt am 22.07.17 21:46 durch Am.....

  7. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 22.07.17 - 21:49

    Am.... schrieb:
    --------------------------------------------------------------------------------
    > Du verstehst da was falsch... HTTP beruht auf TCP! dort gibt es ACK

    sicher das ich es falsch verstehe? Laut dem was bisher von QUIC zu lesen ist, soll es zum ersten ein vollständiger Ersatz für TCP sein und ist primär für Web-Applications gedacht, die normalerweise HTTP nutzen. Somit würde HTTP dann über QUIC statt TCP laufen.

    PS: Und HTTP ist der einzige Traffic der für RTT Messungen interessiert.



    1 mal bearbeitet, zuletzt am 22.07.17 21:51 durch Poison Nuke.

  8. Re: warum kann man die RTT nicht mehr messen?

    Autor: Am.... 23.07.17 - 01:03

    Für mich hört sich das eher so an: UDP dann QUIC und in QUIC wird HTTP encapsulated.
    Da QUIC fast komplett verschlüsselt ist, ist für einen Router, Switch was auch immer nicht erkennbar welche Antwort zu welcher Anfrage gehört. Somit keine RTT ermittelbar.

    Bzw. es ist nichtmal erkennbar was im QUIC übertragen wird https, http, what so ever.



    3 mal bearbeitet, zuletzt am 23.07.17 01:13 durch Am.....

  9. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 23.07.17 - 12:40

    Am.... schrieb:
    --------------------------------------------------------------------------------
    > Da QUIC fast komplett verschlüsselt ist, ist für einen Router, Switch was
    > auch immer nicht erkennbar welche Antwort zu welcher Anfrage gehört. Somit
    > keine RTT ermittelbar.

    dann schreibe ich nochmal was ich oben schon zweimal geschrieben habe:
    HTTP hat bestimmte Übertragungsmuster. Diese sind immer für jeden erkennbar, trotz vollständiger Verschlüsselung. Dadurch wird man mit einer an absolut grenzenden Wahrscheinlichkeit die RTT korrekt bestimmen können ohne zu wissen, was da überhaupt gerade übertragen wurde.

    Euch ist schon bekannt, wie die Enigma im WW2 geknackt wurde, oder? Exakt das Prinzip kann hier auch verwendet werden, denn ein HTTP Request läuft IMMER gleich ab.

  10. Re: warum kann man die RTT nicht mehr messen?

    Autor: Andre_af 24.07.17 - 09:24

    QUIC ist vor allem für CDN Provider ein Bild des Grauens. Der Idee ist vielleicht gut, aber durch die Verschlüsselung und das "reinschaufeln" der Daten in einen einzelnen Request (also HTML, Bild, CSS, alles) kriegen die mit Ihrem momentanen Strategien echt Probleme.

    Beispiel: Viele (grosse) Webseiten referenzieren die Bilder in Ihrer URL von einem anderem Hostnamen (z.B. images.domain.tld). Warum ? Weil da ein CDN hintersteht. Dieses System trennt es so auf, das ein Webserver nur Bilder raus pustet und ein anderer den PHP/ASP/Perl/Python Kram für den dynamischen Webtext ausleitet. Denn diese Systeme "funktionieren" anders. Der Server z.B. der die Bilder anbietet würgt zum einen den Request nicht durch einen Interpreter für eine Sprache, zum anderen (wenn wir mal bei dem Bilderbeispiel bleiben oder alles was statischer Kontext ist) geht man z.B. hin und packt in diese Kisten massiv viel Speicher rein und versucht die ganzen statischen Inhalte nur noch aus dem Speicher rauszugeben. Lastgründe, Zugriffszeiten, Plattenzugriff rausoptimieren usw. - Fragt mich nicht ob z.B die Nummer mit dem fetten Arbeitsspeicher aus dem Bilder kommen echt günstiger ist als ne Platte, ich habs nicht durchgerechnet, ich weiss nur das Akamai das z.B. für statische Bildinhalte genau so tut.

    So und jetzt kommt QUIC. Das transportiert dir alles per UDP vollverschlüsselt ohne SYN und ACK wie bei TCP. Du siehst nichts am Transportprotokoll ausser zusammenhangslose Pakete die da hin und her fltzen. Und was da transportiert wird siehst du auch nicht mehr (bei HTTPS kann man ja wenigstens noch den HTTP Header sehen - aus Sicht des CDN).
    Aus Privacy-Sicht natürlich super, aus Serversicht ein Grauen. CDN funktioniert damit im Moment quasi gar nicht mehr.
    Loadbalancen ist auch schlecht was z.B. Sessions angeht. Ich seh ja nicht mehr welche Session in dem Paket steckt (das Session Cockie steht ja sonst im unverschlüsselten HTTP Header),. Ergo wird es schwer dafür zu sorgen immer dem gleichen Webserver zumindest den Teil der Sitzung mit der Session zu geben. Also brechen erst mal Sessions zum größten Teil kaputt (ausser ich habe einen kruden Session Mechanismus der Serverübergreifend irgendwie werkelt).
    Und die ganzen DS-Light Stack Leute die Ihren IPv4 Kram per Carrier Grade NAT abwickeln und daher zu zehntausenden mit der gleichen IP beim Anbieter aufschlagen machen es auch nicht mehr besser da was zu unterscheiden mit Sender/Empfänger ist ja eindeutig. Das haben wir uns im IPv4 mit NAT einfach quasi kaputt gemacht.

    Fehlersuche will ich auch nicht anfangen.

    Das alles so nette Probleme mit QUIC.

    Übrigens bin ich auch kein Freund der statischen Schlüssel da es einfach das Forward Secrecy kaputt macht. Ich versteh hier beide Seiten. Aber ehrlich ? Ich hab nicht mal ansatzweise ne Idee wie man es praktikabel lösen kann ohne die Verschlüsselung kaputter zu machen. Und das will man eigentlich auch nicht.



    1 mal bearbeitet, zuletzt am 24.07.17 09:29 durch Andre_af.

  11. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 24.07.17 - 09:56

    Andre_af schrieb:
    --------------------------------------------------------------------------------
    > QUIC ist vor allem für CDN Provider ein Bild des Grauens. Der Idee ist
    > vielleicht gut, aber durch die Verschlüsselung und das "reinschaufeln" der
    > Daten in einen einzelnen Request (also HTML, Bild, CSS, alles) kriegen die
    > mit Ihrem momentanen Strategien echt Probleme.
    >
    naja stimmt so auch nicht. Der CDN Provider bekommt ja eh den Request. Die Frage ist halt, wo ist der Endpunkt der Verschlüsselung. Der muss dann eben für die Empfangsrichtung beim Loadbalancer liegen und bei der Senderichtung die jeweiligen Cluster-Knoten des jeweiligen Inhaltes. Es ist kein Problem die Keys über diese Systeme zu sharen, sodass es auch keine Security Probleme gibt.

    Man sollte bedenken, das Protokoll wurde von Google entwickelt, dem Anbieter für verteilte Dienste schlechthin. Wenn die das System so gestalten, das ihr eigenes CDN nicht mehr funktioniert, wären sie schön dämlich... um es mal direkt zu sagen.

  12. Re: warum kann man die RTT nicht mehr messen?

    Autor: traxanos 24.07.17 - 10:55

    > (bei HTTPS kann man ja wenigstens noch den HTTP Header sehen - aus Sicht des CDN).

    Das stimmt nicht. bei HTTPS kann man nicht den HTTP Header sehen! Man kann ggf. den Servernamen sehen, dafür ist allerdings die SNI-Extension notwendig. Daher muss teilweise heute noch für jedes SSL-Zertifikat / VHOST eine eigene IP-Adresse verwendet werden.

  13. Re: warum kann man die RTT nicht mehr messen?

    Autor: Buddhisto 24.07.17 - 11:32

    Ich würde jetzt behaupten das der CDN durchaus den http header sehen kann. Er kennt ja die entsprechenden Schlüssel. Wie und wo der CDN das löst ist ihm überlassen(proxy/load balancer/concentrator).

    Wenn ein CDN/Server Betreiber beschliesst QUICK zu benutzen, wird er wohl auch entsprechend seine Infrastruktur anpassen.

    Was ich mich Frage ist, wie sieht es mit den firewall's auf "end-user"/requester Seite aus. QUICK würde eine Menge UDP Löcher bedeuten. Natürlich zeitlich begrenzt durch die UDP timer Einstellungen der firewall.

  14. Re: warum kann man die RTT nicht mehr messen?

    Autor: Andre_af 24.07.17 - 11:34

    traxanos schrieb:
    --------------------------------------------------------------------------------
    > > (bei HTTPS kann man ja wenigstens noch den HTTP Header sehen - aus Sicht
    > des CDN).
    >
    > Das stimmt nicht. bei HTTPS kann man nicht den HTTP Header sehen! Man kann
    > ggf. den Servernamen sehen, dafür ist allerdings die SNI-Extension
    > notwendig. Daher muss teilweise heute noch für jedes SSL-Zertifikat / VHOST
    > eine eigene IP-Adresse verwendet werden.

    Sorry da war ich wohl gerade falsch abgebogen, natürlich hast du Recht und der HTTP Header ist ebenfalls verschlüsselt und man sieht per SNI dann den Hostnamen. Das setzt natürlich voraus das für einen Loadbalancer das er die Verbindung irgendwie anders wieder zuordnen kann (z.B. indem das in einem TCP Fluss related ist).

  15. Re: warum kann man die RTT nicht mehr messen?

    Autor: Andre_af 24.07.17 - 11:49

    Poison Nuke schrieb:
    --------------------------------------------------------------------------------

    > naja stimmt so auch nicht. Der CDN Provider bekommt ja eh den Request. Die
    > Frage ist halt, wo ist der Endpunkt der Verschlüsselung. Der muss dann eben
    > für die Empfangsrichtung beim Loadbalancer liegen und bei der Senderichtung
    > die jeweiligen Cluster-Knoten des jeweiligen Inhaltes. Es ist kein Problem
    > die Keys über diese Systeme zu sharen, sodass es auch keine Security
    > Probleme gibt.

    ja, das gilt für einen Protokolltransport per TCP wo ich einen eindeuigen Datenfluss designieren kann. Da hab ich ja nen schönen Connect und Ack und Syn etc.
    UDP ist halt Fire&Forget.
    Das bringt dir halt gewisse Probleme ab Dingen wie Carrier Grade NAT beim Provider. Da kommen lauter nicht zusammenhängende Pakete von derselben Quelladresse von wechselnden Ports per UDP und du erkennst keinen Zusammenhang mehr. Das bringt, ab dem Moment wo du nicht nur ne Webseite ohne jeglichen "Sitzungzustand" abrufen willst Probleme. Oder ums banal zu sagen: Dann geht dir Facebook kaputt (Login-Sitzung), aber die Webseite vom Verein der lustigen flinkfingrigen Flaschenschiff-in-die-Flasche-Schieber würde wohl noch weiter tun (solang man sich nicht einloggen muss).
    Der Carrier-Grade-NAT Betreiber würde wohl auch ein bisschen maulen weil sein CGN vorher immer am TCP sehen konnte wenn ne Verbindung zu ist und jetzt braucht er riesige Tabellen um erstmal auf Verdacht irgendwelchen UDP Transit sich zu merken weil er nicht so genau weiss wann er mal so nen Eintrag in der NAT Tabelle wegwerfen kann. Aber das ist eher nen Ressourcenproblem.

    > Man sollte bedenken, das Protokoll wurde von Google entwickelt, dem
    > Anbieter für verteilte Dienste schlechthin. Wenn die das System so
    > gestalten, das ihr eigenes CDN nicht mehr funktioniert, wären sie schön
    > dämlich... um es mal direkt zu sagen.

    Ich sage ja auch nicht das es nicht funktioniert. Wenn man sich mal die reine Idee gegenüber HTTP anguckt hat QUIC auch was charmantes. Ich habe ja nur mal angemerkt das die da so rumrumoren weil das z.B. auch CDN Anbietern viele Ihrer klassischen CDN Strategien über den Haufen wirft. Das ist natürlich unangenehm, weil neumachen kostet halt Geld. Und in dem Fall "richtig" neumachen. Irgendwie reingucken können mit statischem Key geht halt schneller und ist damit billiger. Darauf werden die wohl hinaus wollen.

  16. Re: warum kann man die RTT nicht mehr messen?

    Autor: Poison Nuke 24.07.17 - 12:15

    Andre_af schrieb:
    > Ich sage ja auch nicht das es nicht funktioniert. Wenn man sich mal die
    > reine Idee gegenüber HTTP anguckt hat QUIC auch was charmantes. Ich habe ja
    > nur mal angemerkt das die da so rumrumoren weil das z.B. auch CDN Anbietern
    > viele Ihrer klassischen CDN Strategien über den Haufen wirft. Das ist
    > natürlich unangenehm, weil neumachen kostet halt Geld. Und in dem Fall
    > "richtig" neumachen.

    hm das ist wohl wahr, das nicht mehr alle Strategien von CDNs funktionieren. Aber die Basic-Concepts sind normalerweise nicht betroffen. Und die Provider hatten ja wegen der RTT rumrumort ^^ und das die Messung der RTT nicht das Problem ist, konnte ja gezeigt werden. Vermutlich war das wohl die Ausrede von Akamai und Cloudflare usw, weil die nicht in ihre geheimen Verteil-Strategien blicken lassen wollen

  17. Re: warum kann man die RTT nicht mehr messen?

    Autor: Buddhisto 24.07.17 - 12:22

    > Poison Nuke schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > Da kommen lauter nicht zusammenhängende Pakete von derselben
    > Quelladresse von wechselnden Ports per UDP und du erkennst keinen
    > Zusammenhang mehr. Das bringt, ab dem Moment wo du nicht nur ne Webseite
    > ohne jeglichen "Sitzungzustand" abrufen willst Probleme. Oder ums banal zu
    > sagen: Dann geht dir Facebook kaputt (Login-Sitzung), aber die Webseite vom
    > Verein der lustigen flinkfingrigen Flaschenschiff-in-die-Flasche-Schieber
    > würde wohl noch weiter tun (solang man sich nicht einloggen muss).
    > Der Carrier-Grade-NAT Betreiber würde wohl auch ein bisschen maulen weil
    > sein CGN vorher immer am TCP sehen konnte wenn ne Verbindung zu ist und
    > jetzt braucht er riesige Tabellen um erstmal auf Verdacht irgendwelchen UDP
    > Transit sich zu merken weil er nicht so genau weiss wann er mal so nen
    > Eintrag in der NAT Tabelle wegwerfen kann. Aber das ist eher nen
    > Ressourcenproblem.

    Dem carrier ist es erstmal egal ob tcp oder udp. Mit upd sieht er keine fin's und muss sich udp sessions u.U. länger merken als bei tcp. Aber das musste er bislang sowieso.

    Das mit dem "Sitzungszustand" halte ich für mehr als gewagt. Ich glaube du vermischt hier "network/connection sessions" mit "user sessions". Ich würde mir ernsthaft Sorgen machen wenn mein Provider für die "user sessions" verantwortlich wäre ;). Das Regelt der Browser mit cookies.

  18. Re: warum kann man die RTT nicht mehr messen?

    Autor: Andre_af 24.07.17 - 14:32

    Buddhisto schrieb:
    --------------------------------------------------------------------------------

    > Das mit dem "Sitzungszustand" halte ich für mehr als gewagt. Ich glaube du
    > vermischt hier "network/connection sessions" mit "user sessions". Ich würde
    > mir ernsthaft Sorgen machen wenn mein Provider für die "user sessions"
    > verantwortlich wäre ;). Das Regelt der Browser mit cookies.

    Ich habe da gar nichts vermischt, ich habe angemerkt das es lustige Effekte bei den User Sessions geben könnte je nachdem wie das CDN arbeitet und ich habe angemerkt das UDP sich Ressourcentechnisch anders verhält als TCP an Carrier-Grade-Nats eben weil du keinen klaren Verbindungsfluss hast. Das war beides eigenständig und nicht vermischt und hatte auch keinen Bezug zueinander abgesehen davon das es im gleichen Kommentar vorkam. Natürlich hat dein Provider nur was mit den Paketen (Netzwerkfluss), nicht aber mit den Inhalt (User Session) zu tun (sollte er zumindest nicht, sonst manipuliert er Inhalte deiner Pakete).
    Bitte richtig lesen, sonst könnte ich auch behaupten du vermischt gerade Network Sessions mit Usersession mit Browsercookies bloss weil du es im gleichen Kommentar erwähnt hast.

  19. Re: warum kann man die RTT nicht mehr messen?

    Autor: PuckPoltergeist 24.07.17 - 15:59

    Poison Nuke schrieb:
    --------------------------------------------------------------------------------
    > Am.... schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Da QUIC fast komplett verschlüsselt ist, ist für einen Router, Switch
    > was
    > > auch immer nicht erkennbar welche Antwort zu welcher Anfrage gehört.
    > Somit
    > > keine RTT ermittelbar.
    >
    > dann schreibe ich nochmal was ich oben schon zweimal geschrieben habe:
    > HTTP hat bestimmte Übertragungsmuster. Diese sind immer für jeden
    > erkennbar, trotz vollständiger Verschlüsselung. Dadurch wird man mit einer
    > an absolut grenzenden Wahrscheinlichkeit die RTT korrekt bestimmen können
    > ohne zu wissen, was da überhaupt gerade übertragen wurde.

    Dann wäre die Verschlüsselung Grütze, weil anfällig für chosen plaintext Angriffe. Wenn verschlüsselt wurde, kommt ein Haufen Daten vorbei, aus dem man keine Schlüsse mehr ziehen kann.

    > Euch ist schon bekannt, wie die Enigma im WW2 geknackt wurde, oder?

    In dem man funktionsfähige Geräte in die Hand bekommen hat?

  20. Re: warum kann man die RTT nicht mehr messen?

    Autor: Andre_af 24.07.17 - 16:30

    Übrigens gibt der QUIC Draft auch eigentlich die Antwort warum man RTT nicht messen kann:

    3.2. Measurement of QUIC Traffic

    Passive measurement of TCP performance parameters is commonly
    deployed in access and enterprise networks to aid troubleshooting and
    performance monitoring without requiring the generation of active
    measurement traffic.

    The presence of packet numbers on most QUIC packets allows the
    trivial one-sided estimation of packet loss and reordering between
    the sender and a given observation point. However, since
    retransmissions are not identifiable as such, loss between an
    observation point and the receiver cannot be reliably estimated.

    The lack of any acknowledgement information or timestamping
    information in the QUIC packet header makes running passive
    estimation of latency via round trip time (RTT) impossible. RTT can
    only be measured at connection establishment time, and only when
    1-RTT establishment is used.

    Note that adding packet number echo (as in https://github.com/quicwg/
    base-drafts/pull/367 or https://github.com/quicwg/base-drafts/
    pull/368) to the public header would allow passive RTT measurement at
    on-path observation points. For efficiency purposes, this packet
    number echo need not be carried on every packet, and could be made
    optional, allowing endpoints to make a measurability/efficiency
    tradeoff; see section 4 of [IPIM]. Note further that this facility
    would have significantly better measurability characteristics than
    sequence-acknowledgement-based RTT measurement currently available in
    TCP on typical asymmetric flows, as adequate samples will be
    available in both directions, and packet number echo would be
    decoupled from the underlying acknowledgment machinery; see e.g.
    [Ding2015]

    Note in-network devices can inspect and correlate connection IDs for
    partial tracking of mobility events.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Hessisches Ministerium des Innern und für Sport, Wiesbaden
  2. Hays AG, Stuttgart
  3. KfW Bankengruppe, Berlin
  4. Schaeffler Technologies AG & Co. KG, Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 99€
  2. 99,90€ + Versand (Vergleichspreis 127,32€ + Versand)
  3. (u. a. AMD Upgrade-Bundle mit Sapphire Radeon RX 590 Nitro+ SE + AMD Ryzen 7 2700X + ASUS TUF B450...
  4. (u. a. Sandisk SSD Plus 1 TB für 88€, WD Elements 1,5-TB-HDD für 55€ und Seagate Expansion...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

IT-Sicherheit: Auch kleine Netze brauchen eine Firewall
IT-Sicherheit
Auch kleine Netze brauchen eine Firewall

Unternehmen mit kleinem Geldbeutel verzichten häufig auf eine Firewall. Das sollten sie aber nicht tun, wenn ihnen die Sicherheit ihres Netzwerks wichtig ist.
Von Götz Güttich

  1. Anzeige Wo Daten wirklich sicher liegen
  2. Erasure Coding Das Ende von Raid kommt durch Mathematik
  3. Endpoint Security IT-Sicherheit ist ein Cocktail mit vielen Zutaten

16K-Videos: 400 MByte für einen Screenshot
16K-Videos
400 MByte für einen Screenshot

Die meisten Spiele können nur 4K, mit Downsampling sind bis zu 16K möglich. Wie das geht, haben wir bereits in einem früheren Artikel erklärt. Jetzt folgt die nächste Stufe: Wie erstellt man Videos in solchen Auflösungen? Hier wird gleich ein ganzer Schwung weiterer Tools und Tricks nötig.
Eine Anleitung von Joachim Otahal

  1. UL 3DMark Feature Test prüft variable Shading-Rate
  2. Nvidia Turing Neuer 3DMark-Benchmark testet DLSS-Kantenglättung

  1. Android: Samsung will Android-10-Beta auch für Galaxy Note 10 bringen
    Android
    Samsung will Android-10-Beta auch für Galaxy Note 10 bringen

    Nach den Galaxy-S10-Modellen kommen das Galaxy Note 10 und Note 10+: Samsung will für seine jüngsten Topmodelle bald ein Betaprogramm für Android 10 starten. Für die Galaxy-S10-Geräte soll zudem mittlerweile eine offene Beta verfügbar sein.

  2. Oneplus 7T und 7T Pro: Oneplus-Smartphones sind erstmals bei der Telekom verfügbar
    Oneplus 7T und 7T Pro
    Oneplus-Smartphones sind erstmals bei der Telekom verfügbar

    Oneplus verkauft seine neuen Smartphones neuerdings auch bei der Deutschen Telekom. Das Unternehmen ist der erste deutsche Mobilfunknetzbetreiber, der die Smartphones im Sortiment hat. In einigen Fällen zahlen Telekom-Kunden aber mehr als bei Oneplus.

  3. Video-Streaming: DRM von Disney+ macht Linux-Nutzern Probleme
    Video-Streaming
    DRM von Disney+ macht Linux-Nutzern Probleme

    Eigentlich soll der Streamingdienst Disney+ auch im Desktop-Browser laufen. Laut einem Fedora-Entwickler geht das anders als mit Netflix oder Amazon Prime jedoch noch nicht unter Linux. Ursache ist offenbar das DRM-System.


  1. 10:51

  2. 10:36

  3. 10:11

  4. 09:11

  5. 09:02

  6. 07:56

  7. 18:53

  8. 17:38