TCP i sprawiedliwy podział pasma

2

Wydaje się, że algorytm (y) kontroli przeciążenia TCP rozdziela dostępną szerokość pasma między poszczególne przepływy TCP.

Czy jest jakiś sposób, aby umożliwić (lub ściślej wymusić) sprawiedliwe dzielenie przepustowości na jednym hoście zamiast na przepływie na routerze? Użytkownik nie powinien mieć (łatwego) sposobu na uzyskanie nieproporcjonalnego udziału przepustowości za pomocą wielu równoczesnych przepływów TCP (tak jak robią to niektórzy menedżerowie pobierania i większość klientów P2P).

Obecnie używam routera DD-WRT do współdzielenia domowej linii DSL, a obecnie możliwe jest (nieumyślnie lub złośliwie) zatrzymanie większości przepustowości za pomocą wielu równoczesnych połączeń, które źle wpływają na rozmowy VoIP. Grałem trochę z ustawieniami QoS, ale nie jestem pewien, jak włączyć sprawiedliwe dzielenie przepustowości na podstawie adresu IP (na usługę nie ma opcji, ponieważ większość przepływów to HTTP).

Aktualizacja: Zakładam, że TCP lub TCP-podobne zachowanie kontroli przeciążenia wszystkich przepływów, ponieważ w przeciwnym razie naprawdę nie byłoby sposobu kontrolowania ruchu przychodzącego.

Obecnie kontrola przeciążenia jest zależna od przepływu, a pojedynczy użytkownik z wieloma przepływami spowoduje, że przepływy każdego z nich dławią się z powrotem i ostatecznie ustabilizują się na poziomie 1 / n krotności całkowitej szerokości pasma dla n przepływów.

Czy nie jest teraz możliwe zmodyfikowanie przychodzącej kolejki i algorytmu odrzucania pakietów w taki sposób, że dla każdego użytkownika istnieje „licznik pakietów”, a pakiety są upuszczane na użytkownika zamiast losowo? W ten sposób, jeśli tylko niektórzy użytkownicy faktycznie powodują zatory, tylko ich przepływy będą musiały się dławić, zamiast wszystkich.

Lxgr
źródło
1
Zasadniczo to nie zadziała. Próbujesz kontrolować, jakie pakiety Twój dostawca usług internetowych przekazuje Ci w sieci. Po otrzymaniu pakietu jest już za późno - nieodwołalnie zużyło ono twoje pasmo.
David Schwartz
Ale zawsze mogę upuścić ten pakiet, zmuszając w ten sposób TCP do zmniejszenia przepustowości, prawda? Mam nadzieję, że przepełniające go przepływy są podobne do TCP lub TCP pod względem kontroli zatorów.
lxgr
1
Możesz, ale jest to okropnie nieefektywne, ponieważ właśnie zmusiłeś dane do ponownego wysłania. Kończysz coraz głębsze kolejki po stronie ISP, a informacja zwrotna staje się wolniejsza. I, oczywiście, działa to tylko w przypadku przepływów, które dławią się z powrotem. (QoS nie pomoże, chyba że dostawca usług internetowych to honoruje lub przeciążona jest lokalna sieć Wi-Fi / LAN).
David Schwartz
1
Ale czy nie w ten sposób sam TCP obsługuje kontrolę zatorów? Pakiety są odrzucane, a nadawca dusi się z powrotem. Chcę tylko, aby pakiety były upuszczane „uczciwie”, tzn. Jeśli jeden użytkownik zużyje więcej niż jego sprawiedliwy udział, tylko (lub przede wszystkim) jego pakiety zostaną upuszczone i tylko jego przepływy będą musiały się dławić. Oczywiście oznaczałoby to pomiar aktualnej prędkości pakietów każdego użytkownika i odpowiednie zmniejszenie. Czy to jest możliwe?
Lxgr
1
Tak, ale pakiety nie są odrzucane zaraz po przejściu przez drogi link, na którym ci zależy. Zostają upuszczeni, zanim przejdą przez to. Chodzi o to, aby upuścić pakiet, aby uniknąć ponoszenia kosztów, a nie upuścić pakiet, mimo że już za niego „zapłacił”.
David Schwartz,