Thanks for your reply.
Priority queueing can still help things. As pointed out earlier, if ack packets get higher priority on outgoing while the upstream is congested, that can help relieve things downstream too.
But by how much ?
Let me try to compute it.
TCP MSS is often 1500 these days. I just checked with WireShark, and on my Windows-7 box, it's 1500.
TCP Acknowledgements are 40 bytes.
Let's assume we talk ADSL here. ADSL has (relatively) a lot of overhead. Especially for acks. So it is potentially the worst case.
How many bytes does a TCP data-packet take on average ? Data + IP header + TCP header = 1500 bytes. Add 8 bytes PPP header plus 8 bytes AAL5 header. That's 1516/48= 31.58 atm-cells. So a TCP data packet takes 32 cells. (An ATM cell is 53 bytes, 5 bytes cellheader and 48 bytes payload).
A TCP ack takes 40 bytes. Plus 8 bytes PPP header plus 8 bytes AAL5 header. Is 56 bytes. That doesn't fit in one cell, so you'll need 2 cells.
Now most TCP implementations will send 1 ack for every 2 data packets received. That means we can receive 64 cells data-packets, and we only need to send 2 cells with an ack. That means that the ratio between downstream and upstream needs to be 32:1 at worst.
In other words, if you have a 4 Mbps downstream ADSL, you need only 128 Kbps upstream for the acks. Any bandwidth you have more than 128 Kbps can be used for things like Skype, gaming, etc.
My conclusion: prioritizing acks in the upstream is going to have very little impact on downstream traffic. Unless your downstream/upstream is way out of balance. (Aka more than 32:1. I think even 10:1 is uncommon. I have long/bad copperwires, and I have 6.5 Mbps down/768Kbps up. Which is only 8.3:1. Far from 32:1).
No, there is no real way to help downstream if the downstream is totally blocked up
Good. We agree here.
Although the situation can still be improved if 1) your router did traffic shaping on acks, or 2) your ISP would configure their DSLAM or CMTS with some form of priority-queuing.
but if the UPSTREAM is also blocked up, the downstream will also be effected as ACK packets begin to take to long to get sent out, so downstream data packets end up getting held up or retransmitted to you.
As I showed, that won't happen unless downstream and upstream are severely out of balance (32:1 or more).
So QoS/priority Queueing can help some.
On the downstream path, yes. On the upstream path, the effect will be much smaller. Unless you use an application that has relatively large upstream. And even then, you need something on the downstream path, or else you'll still experience congestion.
Think of it more like turning the emergency lights on the packets while stuck in a high way of traffic (but with no shoulder). ..<snip>
No need for simplified analogies. I know how to read an RFC. Please be more specific.
Actually if you have a rather large pipe, then even if it is 100% utilized by something, small traffic demands won't result in greatly increased latency.
Latency isn't a result of 100% utilization. It's a result of queue-depth. And FIFO scheduling. And even tail-drop behaviour. With proper queueing and drop-strategies, you can still guarantee low latency for some applications, while maintining (close to) 100% line utilization.
Sure, the bandwidth is reduced for each TCP stream as you only have a pipe that is so large. However, at, say, 75Mbps if a single ack packet has to get sent out, that is a MUCH smaller delay than if a fully utilized 1Mbps connection was being used...by a factor of 75 and that ACK packet also takes up 1/75th of the pipe that it would on a 1Mbps connection too!
Not sure what your point is. Speed itself does not change the problem. It might help if the application itself has a maximum bandwidth (e.g. when you watch a video). But not when applications try to maximize their bandwidth (e.g. most download protocols).
On the downstream, similar thing, you have a loaded 75Mbps pipe, if you spin up a 5Mbps Netflix stream, the TCP stream is losing only a small mount to the Netflix UDP video stream and it only takes a small amount longer for various packets to come in. Now with a 3Mbps downstream pipe, if you even tried to bring up a 300Kbps email download while the connection was being 100% utilized by streaming youtube videos...that is going to cause a lot more havoc.
That depends. First of all, it's only a 10% change in available bandwidth. Second of all, email does not try to download at a certain speed, it tries to get the maximum (of its fair share), just like all tcp-based protocols. In your example, when Netflix and your email (a big TCP download) conflict, Netflix will probably not back off, but email will. Result: email not a problem for Netflix. Third of all, email isn't interactive, so it doesn't matter if it takes 1 second or 100 seconds to download.
But I understand what problem you try to describe here.
I still don't see how my router at home can influence downstream traffic. And everyone on this forum (and in other conversations) always says: "just configure your router with QoS, problem solved". I can't believe that's true.
Priority Queueing/QoS CAN help with things, but it is a bandaid on an amputation a lot of times. Oh, sometimes it can do wonders, but it does not cure the underlying issue.
I think it does. If you do proper priority-queueing. In both directions. My ISP seems to do something, and it already helps a lot. I can game (e.g. play a MMO) without any noticable problems, while I have my downstream fully utilized by downloads. This has not always been the case. But it seems to be since a year or 2-3.
It can make gaming be bearable maybe, but then you are nailing some other service that now has greatly increased latency or a much smaller pipe to work with (then again, maybe the service that has greatly increase latency or a smaller pipe can tolerate that a lot more gracefully. Perhaps you don't mind that your YT video got bumped down to 360p...but now you only have 40mS latency in your game, where as before you were doing fine with 480p streaming, but had 600ms of latency gaming).
Gaming usually uses very little bandwidth. So does voice-com. In the order of 64k (with proper codexes, etc) or less. It is my believe that low-bandwidth services should be able to get all the priority they want. And downloads get the lowest priority.
The odd one out is video. Many people believe video needs highest priority. I disagree. Because video is/can be buffered. I really don't care if my YT or Netflix packets get lowest priority, have some drops, and have 200ms delays. A few seconds of buffering takes care of that. As long as they get 80-90% of the bandwidth.
But still, I do not understand how people can tell the OP that his situation will improve by fiddling with his home-router. I think it can only be solved if his ISP does something on their router (DSLAM or CTMS or fibre-router or whatever is the last step before his house). Only the downsteam path. People discuss which home-router to buy. Please explain.
Facebook
Twitter