Subject: Re: [MMUSIC] delay API (was: Packet drop API / what happens with packet drops now?)

From: [email-masked]
Date: Fri, 25 Jul 2003 19:05:14 +0200

Eddie,

>What happens in currently-deployed codecs when packets are dropped?
>

all recent codecs can handle substancial amounts of loss
(that is: well implemented decoders can ;-) but mimizing
losses should remain the highest priority because
the perceived quality for (X-loss) is always
smaller than if the codec had produced (X-loss)bits
in the first place.

>Clearly codecs, and VoIP in particular, can handle loss. Possibly even high
>loss rates. One way to think about DCCP's allowed sending rate is that it
>moves drops that *would* have happened in the network *anyway*, into the
>sending host. (Although DCCP will generally drop more than the network
>would have, to ensure fairness, and because of congestion-control
>infelicities that we want to fix.) So how disastrous are these drops?

What is desirable is that DCCP tells the sender "dont send that much!"
and as Tom expressed it:

>"it seems better to me that the sender makes intelligent
>decisions about packet discard, rather than the network makes random
>decisions

which also apply to the DCCP stack (sender side):
it is not in a good position to make the best decision.

>Another way to put this: A DCCP API might never block -- or it might block
>for at most T seconds. Instead, writing a packet into a full send buffer
>would drop that packet; or it might drop an older packet---a drop-from-head
>send buffer; or it might drop the oldest packet with lowest priority
>annotation.
>
>Now the app simply sees a loss rate, which DCCP will happily report. For
>codec switching, you can simply switch when the loss rate is intolerably
>high -- which you would have had to do anyway.
>
>How horrible would this be?

You make it sound like the DCCP sender API would be some mysterious black hole?-)

I vote for "extremely horrible"?-)

What about a *delay* API:

When the rate changes the application is notified
(e.g. a call back would be nice, at startup an application
would be able to pass a rate callback pointer function)

If the application complies i.e. waits the right amount of time
between each packet and/or send packets with the right size
so that its rate is below the indicated rate, then all is good.

If the application does not comply (sends a packet too soon and/or too big) the API replys:

"This packet will be sent, but with a delay of xxx ms"
(and *sends* it, the delay being computed to match the current CC max rate)

obviously such a message implies that the sender is sending with a rate too high...
(at that stage an application which passed "null" at startup
for the rate callback pointer function can use an explicit call
to get the rate...)

If the application sends *really* too much
the API returns with *increasing delays* until a
more severe error occurs: "packet not accepted, buffer is full".

In short, the (int) returned by "send" would not be
the amount of data sent but the amount of *delay*
the packet will suffer before flying out.
Zero meaning the application rate is below the max (TFRC) rate.

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic