> The problem isn't the buffered video but the IP level buffering that
happens on big tcp downloads... that's why I filed it against
networking first
I don't follow--the OS buffers for a TCP socket are much smaller than
the media cache's buffer. Or are you talking about clogging router
buffers? I still don't see how necko doing the suspend/resume vs the
media cache makes a difference here.
yes, router buffer of the bottleneck link. That's where the problem is
and where the problem can be slow to clear - once data is at the host
its not an issue for anything but ram.
if necko can do it we can apply the code to things other than media
consumers (e.g. download window) where the notion of appropriate rate
might be derived from some shared state about all the necko connections
- so we don't want to push that decision out to the end consumer who
doesn't have visibility into all the other transfers.
additionally, there are things necko can do other than just stop reading
on suspend.. it can slam rwin (the recv buffer) down to ~0, which is
going to stop the transmit faster in the presence of large windows (and
windows larger than bw*delay are the heart of bufferbloat),
alternatively it can just reduce rwin to something smaller than bw*delay
to effectively slow the transmission rate and make sure the bottleneck
link gets its buffers cleared at least once every rtt.. etc.. etc..
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
