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

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 24 Jul 2003 21:40:27 -0400

Hi Eddie,

I actually think that there's a big advantage to throwing packets away at
the sender, rather than having the network choose the packets to throw away,
even if you end up discarding more packets that way.  When the sender
chooses the packets to discard, it can ensure that important packets (like
frame markers, etc.) are preserved.  The network simply makes random
decisions.

Tom P.

> -----Original Message-----
> From: Eddie Kohler [mailto:[email-masked]]
> Sent: Thursday, July 24, 2003 6:21 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Packet drop API / what happens with packet drops now?
> 
> 
> 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: Damon Lanphear <[email-masked]>
Date: 25 Jul 2003 09:23:04 -0700

I agree with Tom.  I think that rather than dropping packets on write in
the sending DCCP, you'd want to block and let the app decide whether the
blocked packet should be queued in the app or dropped.  One of the
things we can do for live unidirectional media, as an example, is prune
an app layer queue to smoothly degrade perceptual distortion based on a
prioritization scheme.

On Thu, 2003-07-24 at 18:40, Phelan, Tom wrote:
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
-- 
Damon Lanphear <[email-masked]>