Subject: [MMUSIC] Packet drop API / what happens with packet drops now?

From: Eddie Kohler <[email-masked]>
Date: Thu, 24 Jul 2003 15:20:38 -0700

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

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?

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?

Eddie

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Jul 2003 01:46:39 -0400

Eddie,

It is really quite a bit worse to through away the packet at the 
sender, as opposed to informing the application and having it respond 
by ceasing transmission or lowering its rate. The difference has to do 
with error propagation that result from compression algorithms. The 
loss of a single packet causes reconstruction errors in the decoder, 
which propagate into subsequent audio frames or video macroblocks. The 
lower the rate, the longer these artifacts persist. If the sender 
knows that it cannot send, it is much better to back off in a way that 
does not result in a desynchronization of encoder and decoder state.

Indeed, I performed some studies to look at this phenomenon as part of 
my dissertation work. For G.729 (an 8kbps audio codec), I found that 
it was much more useful to keep the the state of the encoder and 
decoder synchronized than it was to faithfully reconstruct the speech 
content of a lost frame, due to this error propagation. The results, 
if you are interested, are described in:

http://www.jdrosen.net/e6880/index.html

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com