On Mon, Oct 14, 2013 at 01:15:31PM +0200, Michael Welzl wrote:
> At least to some degree, this must be a function of the queue length, I
> think. The shorter your queue, the less likely it is that you see more than
> one packet from the same source... if important packet #1 from source X and
> unimportant packet #2 from source X are not in the same queue together, you
> probably can't reasonably protect #1 from the impact of #2.
Indeed. IN other words you need some number of multiplexed flows to
effectively do intelligent dropping. I think this may be as low as
3..4 flows on a home-gateway, but the more, the better.
> There, I think the answer can easily be found in multimedia literature. There
> are many papers out there that evaluate such effects, e.g.:
> Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video
> Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID
> 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil.
> as only one example.
Thanks for the pointer.
> > - How do you motivate codecs to indicate packet priorities if they have to
> > fear that video flows with some packets marked "low priority" would
> > ultimately see more packets dropped than flows without any "low priority"
> > indications. For that we've got draft-lai-tsvwg-normalizer-02.txt
>
> Well, but here we're talking about a marking that only means "relative
> priority, within the same connection". So there shouldn't be any risk in
> setting low priority, really.
But you need an intelligent dropping mechanism, and unless you would
do a per-flow subqueue, you could not do relative dropping relative within
the flow). And per-flow queuing is expensive. So our draft tries to explain a
scheme
that replaces per-floq queuing with per-flow priority remarking to allow
dropping in a common queue.
Cheers
toerless
> Cheers,
> Michael
>
--
---
Toerless Eckert, [email protected]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!
