Ralf Ertzinger wrote:
Hi.
On Tue, 11 Mar 2008 22:15:47 -0500, Bruno Wolff III wrote:
If you are talking about the qos flags in IP packets, the answer is
no. There aren't that many states and generally you can only describe
broad things about packets (such as I want low latency or I want high
throughput) not detailed bandwidth allocations.
You can do bandwidth allocation based on QoS flags (with the newer DSCP
interpretation of the relevant IP header flags you get 64 possible traffic
classes, which is quite a lot).
Also I tried a few
experiments with testing qos bits and found that they seemed to be
getting stripped (I expected them to be ignored, but that at least
they would be preserved) in transit. I didn't do enough experiments
to see where this was happening or to get a good idea of how common
this was.
On the other hand QoS is very much an end-to-end process, which means
that all involved devices (as in: routers) have to agree on the QoS
policy (which DSCP flag signifies which traffic class, and what preference
this traffic gets). This is why it is does not work over the internet
as a whole. Your provider usually has a diffenent view on what constitutes
important traffic, and thus strips your classification (or does not strip
it but ignores it).
I was thinking more along the lines of just the local machine's behavior with
different connections having higher or lower priority for outbound (which is
often what hurts response time the most for slower connections while longer
running transfers occur). I really don't know how effective QOS is, so it may
be a bad way to approach this issue.
If an update connection had low priority for the bandwidth resources, that
connection should be postponed whenever a higher priority connection wants to
push outbound traffic. A browser then would get to send its page requests or
acks ahead of running transfer packets from the update utility; the result would
be a much more responsive browser while still using most of the available
bandwidth. Whether the QOS flags are being stripped/mangled once the traffic
leaves the local machine should not really hurt that improvement would it?
I'm just thinking it may not require full end-to-end to enjoy some benefit. The
incoming connection would not be slowed or postponed to let the browser respond,
but by not acking what comes in until the outbound clears up I think it might
help anyway.
--
Andrew Farris <lordmorgul@xxxxxxxxx> www.lordmorgul.net
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
