Timeline for Upstream QoS garanteed bandwidth
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 22, 2020 at 21:01 | comment | added | Marc 'netztier' Luethi |
Yes multiple, parallel TCP streams (with unscaled TCP receive windows) can saturate what is called a "long fat pipe" (a link/path with a high bandwitdh * delay product). If you can get the receiving end to scale up its receive window size (use -w <buffersize>), you should be able to manage with a single stream. My apologies for not clearly stating that both, but in particular the receiver (iPerf: the "server") must scale up its receive window.
|
|
| Apr 22, 2020 at 13:46 | comment | added | vudex | So, I retested it with -P flag (parallel tcp streams) and with 3 and 4 tcp streams bw actually does allocate. So it might be bottleneck of single tcp stream over satellite link. | |
| Apr 22, 2020 at 13:01 | comment | added | Ron Maupin♦ | The latency will kill the TCP tests, and per @Marc'netztier'Luethi suggestion, remember that you mark traffic as close to the source as possible. We found that doing it all on the router really kills the router throughput. | |
| Apr 22, 2020 at 7:33 | comment | added | Marc 'netztier' Luethi | Another tripwire to avoid: (depending on platform) egress (in extenso: queuing) QoS class-maps/policy maps can not always match on the same set of criteria as ingress class-maps/policy-maps do (without having checked: matching on tcp/udp ports with an ACL or on application using NBAR fall in this category). A safe strategy against this is to match and mark traffic upon ingress into the device (by setting DSCP or IP Precence), and to just match on DSCP or Precedence for queuing/shaping on the egress side. | |
| Apr 22, 2020 at 5:35 | comment | added | vudex | @Marc'netztier'Luethi I will try out you suggestions. Yes, I knew that saturation of the link must be the case for QoS to start working. I thought that shape average in parent policy should account for that (I particularly made it below than average throughput on the graph). Also I tried bandwidth commnand on the interface, but after that I read that with parent - child policy it's not necessary. | |
| Apr 22, 2020 at 5:14 | comment | added | Marc 'netztier' Luethi | Also: Please remember that QoS only kicks in once a link/interface (or: your parent shaping class) gets saturated. If you'll want to see these 1.5Mbps guaranteed for that single host, you'll have to have other traffic actually saturating/oversubscribing that link. | |
| Apr 22, 2020 at 5:08 | comment | added | Marc 'netztier' Luethi |
Can you actually achieve the ~7Mbit/s upstream through that path? Satellite links are usually high latency, and this increases the bandwidth * delay product (a.k.a. "bytes in flight") way beyond (unscaled) TCP receive windows of the end systems. Use switch.ch/network/tools/tcp_throughput or wintelguy.com/wanperf.pl to play with some numbers). Depending on host OS, you might have to make sure that iPerf makes the TCP receive window scale with -w <buffer size>. Alternatively: just send off UDP at the desired rate.
|
|
| Apr 22, 2020 at 4:49 | history | edited | vudex | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Apr 22, 2020 at 4:48 | comment | added | vudex | @RonMaupin yes, it's TCP | |
| Apr 22, 2020 at 4:40 | comment | added | Ron Maupin♦ | Is this TCP you are testing? | |
| Apr 22, 2020 at 3:57 | history | asked | vudex | CC BY-SA 4.0 |