Glasfaser FTTH: 1&1 Versatel erhält Zugriff auf Glasfaser der Telekom

[0-8-15 User]

Was TCP (das mit Abstand am Re-Ordering sensitivste Protokoll) ja schon im Header eingebaut hat...

UDP hat in der Tat keine Sequenznummer.... aber dann haben Middleboxen ohne zusaetzlichen Header keine Moeglichkeit die Reihenfolge wieder herzustellen.

So wie ich das oben verlinkte RFC verstehe, geht es nicht darum, die ursprüngliche Reihenfolge, mit der die Pakete vom Sender abgeschickt wurden, wiederherzustellen, sondern nur darum, dass die - ggf. bereits veränderte - Reihenfolge auf der Bondingstrecke erhalten bleibt, sprich die Laufzeitdifferenz der Tunnelstrecken für Sender und Empfänger möglichst transparent ist.

dass wenn Paketverluste auftreten der Re-Order sich überlegen muss wie lange er maximal warten will, und das führt dann zu Jitter und oft noch schlimmer zu bursty Transmission aller Pakete die bereits out-of-order angekommen waren....

Ich denke, das hängt davon ab, wie man es konkret implementiert, aber ich hab mir zugegeben noch keine großen Gedanken darüber gemacht - eventuell lieg ich auch falsch.

 

[pufferueberlauf]

Guter Punkt. Es gibt noch einen wichtigen Grund warum man nicht TCP sequence nummern beim re-sequencing bei einem Tunnel 'unterwegs' verwendet (zusaetzlich zum Problem mit UDP) und zwar muesste man jeden TCP Flow individuell re-sequenzieren und das ist aufwendig, zu aufwendig....
Aber das heist dass man auf paralellisierten Streckenabschnitten halt eine Verkapselung braucht die Sequenznummern enthaelt....

Ach ja es gibt Bestrebungen in der IETF TCP etwas robuster gegen das heutzutage erwartbare Ausmass an re-ordering zu machen: RACK aber bevor sich das nicht durchgesetzt hat muss man halt noch Ruecksicht auf alte TCPs nehmen (voraussichtlich noch fuer laaaange Zeit).

 

[robert_s]

Aber das heist dass man auf paralellisierten Streckenabschnitten halt eine Verkapselung braucht die Sequenznummern enthaelt....

Dafür gibt's ja seit über 20 Jahren schon RFC 2890, und da steht ja auch schon alles drin:
https://datatracker.ietf.org/doc/html/rfc2890

Use of the sequence number option should be used appropriately; in particular, it is a good idea to avoid using when tunneling protocols that have higher layer in-order delivery mechanisms or are tolerant to out-of-order delivery.
If only at certain instances the protocol being carried in the GRE tunnel requires in-sequence delivery, only the corresponding packets encapsulated in a GRE header can be sent with the sequence bit set.

Ach ja es gibt Bestrebungen in der IETF TCP etwas robuster gegen das heutzutage erwartbare Ausmass an re-ordering zu machen: RACK aber bevor sich das nicht durchgesetzt hat muss man halt noch Ruecksicht auf alte TCPs nehmen (voraussichtlich noch fuer laaaange Zeit).

Möglicherweise mit abnehmender Relevanz, denn schließlich ist TCP ja schon teilweise durch QUIC abgelöst, Tendenz vermutlich steigend.

 

[pufferueberlauf]

Dafür gibt's ja seit über 20 Jahren schon RFC 2890, und da steht ja auch schon alles drin:

Mein Punkt sollte sein, dass man immer noch zentralisierte Ein- und Aispack-Stationen braucht, was deutlich weniger attraktiv fuer die Bitschubser ist als Pakete einfach per hash oder Zufall ueber 2 oder mehrere parallele Pfade zu schicken und sich nicht ums Re-Sequenzing kuemmern zu muessen...

Möglicherweise mit abnehmender Relevanz, denn schließlich ist TCP ja schon teilweise durch QUIC abgelöst, Tendenz vermutlich steigend.

Oder auch nicht... die Bitschubser die im NaNog organisiert sind, sind grosse Fans von Ratelimits fuer UDP... do oder so wird TCP noch lange wichtig genug bleiben als, dass die Backbone-Bauer nicht einfach Techniken ausrollen werden die bei TCP Probleme machen...

 

[0-8-15 User]

in particular, it is a good idea to avoid using when tunneling protocols that have higher layer in-order delivery mechanisms or are tolerant to out-of-order delivery.

Genau das trifft aber in meinen Augen nicht mehr zu, wenn man die spezielle Situation betrachtet, die sich durch das Bonding zweier Links mit unterschiedlichen mittleren Umlaufzeiten ergibt. Im RFC8157 steht:

Values larger than the difference of the normal Round-Trip Time (RTT) (e.g., 100 ms) of the two connections are not recommended. Implementation and deployment experiences have demonstrated that there is usually a large margin for the value of MAX_PERFLOW_BUFFER. Values larger than the multiplication of the sum of the line rate of the two connections and the value of OUTOFORDER_TIMER should be used.

Bei Hybrid liegt die Datenrate pro Verbindung bei ~ 100 Mbit/s und die Laufzeitdifferenz bei ~ 20 ms und das kommt für mich zumindest auf den ersten Blick aufs Gleiche raus wie das Bonding von zwei 1 Gbit/s FTTH Anschlüssen mit einer Laufzeitdifferenz von ~ 2 ms.

 

[Nore Ply]

Wollt ihr für eure In-deep-Diskussion über TCP-Parameter nicht mal langsam einen eigenen Thread eröffnen?

 

[pufferueberlauf]

IMHO ist das Problem, dass das Gross an Traffic immer noch TCP ist, und das ist halt recht OOO intolerant, i.d.R. reicht es ein Paket (N) 3-4 Pakete nach hinten zu schieben (so dass N+1 bis N+3 am Empfänger ankommen bevor N eintrudelt) diese lösen dann jeweils ein DupACK aus, also ein ACK Paket mit gleicher Acknowledgment number, und ab ~3-4 DupACKs geht der Sender von Datenverlust aus und reduziert sein congestion window, was effektiv die Datenrate reduziert. D.h. wenn TCP im Spiel ist, muss der Ent-Bonder letztlich die Reihenfolge wieder her stellen... im Prinzip kann man das so gestalten, dass man das selektiv nur fuer TCP macht, aber dazu muss man dann halt schon jedes Paket anfassen (was Prozessierungskosten verursacht) und man läuft in das Problem, dass z.B. ein UDP-Wireguard-Tunnel der selber überwiegend TCP transportiert fälschlicherweise nicht re-sequenziert wird. Mit anderen Worten wenn man nicht genau über die Traffic-Zusammensetzung informiert ist, ist es sicherer schlicht alle Pakete zu re-sequenzieren.
Aus diesem Grund wuenschen sich die Bitschubser, wie gesagt, dass neue Protokolle alle toleranter gegen out-of-order delivery werden... (IMHO ist das prinzipiell keine schlechte Idee, solange wir nur davon reden statt 3 dupACKs, z.B. 1-2 RTTs als Re-sequenzierungsfenster zu verwenden, aber das duerfte den Bitschubsern nur bedingt helfen). Das Problem dabei ist halt, dass ein Stream-Protokoll wie TCP Daten nur bis zum ersten Loch an die Applikation weiter gibt, d.h. die Anwendung ist bis zum Eintrudeln des ausstehenden Paketes blockiert, wenn ein Paket echt verloren war fuehrt RACK halt dazu, dass es zu etwa einer RTT extra Latenz kommt. Und das heisst dass es insgesamt besser ist, wenn das Backbone keine unnoetigen Sequenzaenderungen erzeugt.
Das ist ähnlich zum Memory-Odering Problem bei CPUs, fuer die Hardware-Macher sind schwächere Garantien einfacher (erlauben schnellere Implementierungen mit weniger Aufwand) während in Software stärkere Garantien effizienteren Code erlauben (wenn die Hardware entsprechend performant ist)... als Endkunde ist mir die Backbone/Hardware Seite weniger wichtig.

 

[KernelMaker]

Schade, auch bei mir ist der 1&1 FTTH ganz normal über die Telekom geschaltet. Identisches Gateway, identischer IP-Pool. Daher auch identisch (beschissenes) Peering

Auch dieser Anschluss hat ein hartes Limit bei 950Mbit. Also bei mir wieder keine 1100 möglich
Allerdings gehen mehr als Gigabit durch, wenn beide gleichzeitig ausgelastet werden.

 

[gendel2]

Danke für die Info. Es verdichten sich die Meldungen zu einer Gewissheit. Dann bleibe ich bei Vodafone-Kabel.

 

[rezzler]

Schade, auch bei mir ist der 1&1 FTTH ganz normal über die Telekom geschaltet. Identisches Gateway, identischer IP-Pool. Daher auch identisch (beschissenes) Peering

Hast du einen 1&1-DSL-Anschluss in der Nähe zwecks Breitband-PoP?

 

[blastinMot]

Auch dieser Anschluss hat ein hartes Limit bei 950Mbit. Also bei mir wieder keine 1100 möglich
Allerdings gehen mehr als Gigabit durch, wenn beide gleichzeitig ausgelastet werden.

D.h. du hast nun Telekom FTTH und 1&1 FTTH parallel?
Gab's Probleme bei der Schaltung?

 

[KernelMaker]

Hast du einen 1&1-DSL-Anschluss in der Nähe zwecks Breitband-PoP?

Ja, hatte ich mich zu erkundigt. Scheint aber egal zu sein für FTTH.

D.h. du hast nun Telekom FTTH und 1&1 FTTH parallel?
Gab's Probleme bei der Schaltung?

Genau.
Probleme nicht. Hat nur ein bisschen gebraucht den Techniker davon zu überzeugen, dass der Anschluss nicht in der Wohnung, sondern im Keller ist

 

[robert_s]

Schade, auch bei mir ist der 1&1 FTTH ganz normal über die Telekom geschaltet. Identisches Gateway, identischer IP-Pool.

Und der OLT-Port? Auch gleich oder ein anderer?

Auch dieser Anschluss hat ein hartes Limit bei 950Mbit. Also bei mir wieder keine 1100 möglich
Allerdings gehen mehr als Gigabit durch, wenn beide gleichzeitig ausgelastet werden.

Anhang anzeigen 1215208

Nicht mal 2x950. Bei mir bekomme ich mit 2xGigabit-Ethernet zu 2 Kabelmodems tatsächlich die 2x940=1880Mbit/s heraus, die Gigabit-Ethernet hergibt...

 

[NDiCB]

1. Anfangs nur DSLite, nach Anruf bei 1&1 dann "richtige" IPv4 Adresse
2. Es ist aber eine Telekom IP (samt Telekom Routing), Nachfrage bei 1&1: das bleibt auch so und kann nicht auf 1&1 IP geändert werden.

Hatte ich auch schon gehört, dass bei den 1und1 FTTH-Anschlüssen über Telekom-Technik noch kein L2-BSA verwendet wird (siehe hier auch Beitrag #248). Aber ich denke das kann sich in Zukunft noch ändern.

Was mich jedoch verwirrt, wenn es sich anscheinend um einen Telekom WIA Anschluss handelt weshalb da bei IPv4 CGN bzw. DS-Lite zum Einsatz kommt. Das wäre mir neu bei Telekom WIA. Kannte ich bei 1und1 bisher doch nur von den L2-BSA Anschlüssen… 😕

 

[KernelMaker]

DS-Lite ist es nicht. Ganz normal die Telekom Adressierung. IPv6 ebenfalls identisch.

Allerdings gibts wieder eine 24h Zwangstrennung. Bei der Telekom-Leitung nicht.
Kann man das bei 1&1 irgendwo deaktivieren?

 

[pufferueberlauf]

Allerdings gibts wieder eine 24h Zwangstrennung. Bei der Telekom-Leitung nicht.
Kann man das bei 1&1 irgendwo deaktivieren?

Gute Frage. Zumindest die Unterlagen fuer WIA-Gate und WIA-Connectivity der Telekom enthalten keinen Passus der explizit 24 Stunden Sitzungsdauer erwähnt, d.h. kann sein, dass das eine 1&1 interne Vorgabe ist.

 

[Mettwurscht]

Wow, da hat man ja das "beste" aus beiden Welten: Telekompeering mit 24h-Trennung der PPPoE-Sitzung. :/

 

[pufferueberlauf]

Wobei, um mal was positives zu WIA zu sagen, die Telekom bis auf die Übergaben ein ordentlich geführtes und gut gewartetes Backbone betreibt... das macht es auch so frustrierend, es mangelt am Wollen nicht am Können...

 

[hantelfix]

hallo

kann es sein das 1und1 die glasfaser tarife 5 euro teurer gemacht hat als telekom

 

[Comadevil]

Bei 50 und 100 Mbit ist es so. Bei 250 Mbit ist der Preis gleich.