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. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Sahle Baubetreuungsgesellschaft mbH, Greven
  2. Zweckverband Bodensee-Wasserversorgung, Stuttgart
  3. CYBEROBICS, Berlin
  4. Ryte GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 2,99€
  2. 0,49€
  3. 59,99€ für PC/69,99€ für PS4, Xbox (Release am 4. Oktober)
  4. 2,22€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Watch Dogs Legion angespielt: Eine Seniorin als Ein-Frau-Armee
Watch Dogs Legion angespielt
Eine Seniorin als Ein-Frau-Armee

E3 2019 Elitesoldaten brauchen wir nicht - in Watch Dogs Legion hacken und schießen wir auch als Pensionistin für den Widerstand. Beim Anspielen haben wir sehr über die ebenso klapprige wie kampflustige Oma Gwendoline gelacht.


    Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
    Ada und Spark
    Mehr Sicherheit durch bessere Programmiersprachen

    Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
    Von Johannes Kanig

    1. Das andere How-to Deutsch lernen für Programmierer
    2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
    3. Software-Entwickler Welche Programmiersprache soll ich lernen?

    Ocean Discovery X Prize: Autonome Fraunhofer-Roboter erforschen die Tiefsee
    Ocean Discovery X Prize
    Autonome Fraunhofer-Roboter erforschen die Tiefsee

    Öffentliche Vergaberichtlinien und agile Arbeitsweise: Die Teilnahme am Ocean Discovery X Prize war nicht einfach für die Forscher des Fraunhofer Instituts IOSB. Deren autonome Tauchroboter zur Tiefseekartierung schafften es unter die besten fünf weltweit.
    Ein Bericht von Werner Pluta

    1. JAB Code Bunter Barcode gegen Fälschungen