Timeline for Downstream QoS Feasibility
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 15, 2016 at 10:54 | history | edited | KillianDS | CC BY-SA 3.0 |
deleted 9 characters in body
|
| Jan 16, 2015 at 8:10 | comment | added | KillianDS | @DanielThompson yes of course it 'works', but as I say there is absolutely no point in dropping the ACK, dropping the original packet (that is going to be ack'd) is way more efficient. Alternatively you could try to manipulate rwnds. The main issue with all those approaches is that it is extremely hard to measure the impact of the router's action on rwnd, cwnd, ssthresh and thus the actual throughput. Without doing some very heavy per-stream analytics you would likely not achieve much more than killing user experience. | |
| Jan 14, 2015 at 1:32 | comment | added | DTD | I think I need to clarify the first part of my question: I'm asking if there's any way for the router at the end-user premises to effectively slow down inbound traffic. In a scenario where the ISP is unwilling to build QoS policies on their edge router (depressingly common) there's no way to queue before the packets hit (and have a chance to saturate) the circuit. The theory is that by dropping ACKs at the premises you can artificially force TCP congestion avoidance to slow down how fast the server tries to send data. I just don't know if it really works. | |
| Jan 12, 2015 at 13:06 | history | answered | KillianDS | CC BY-SA 3.0 |