Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Nov 2003 14:06:42 -0500

This would seem to only apply to a non-interactive stream, where
several seconds of buffering is acceptable, correct?
You also, in this case, would not actually change the encoding
rate, but merely change the instantaneous transmit rate.

I'm not clear on how this is better than just using TCP.

Brian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2003 10:40 AM
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> 
> 
> Lars-Erik,
> 
> I share your concern about "sending garbage" to "keep the pipe open".
> 
> I understand now that "probing" is required to achieve (2) in 
> fairness to TCP
> i.e. a traffic that is competing with TCP has to use the same 
> "weapon".
> 
> My idea would be that if the TCP traffic is allowed to push 
> the DCCP-born media traffic down in rate
> I expect "probing" to be performed in order for the media 
> traffic to discover that it can increase its rate,
> **after a decrease**, if/when it can, i.e. when some/all of 
> the TCP traffic is finished (which would be fair).
> 
> In short for media traffic via DCCP "probing" would be a 
> continuous activity in order to push against
> the TCP traffic,(the amount of pressure/resistance being tunable ?)
> 
> I am expecting a TCP-well-behaved media application to lower 
> its rate (but not systematically by half ?)
> if more TCP traffic happens and I also assume that all media 
> applications should be
> prepared/defined to either stop reducing their rate AND/OR 
> cut off below a certain rate,
> i.e. this should be tunable by marketing/policy/management.
> 
> I agree with Stephen that in all case probing means losses on 
> both sides but
> I expect error resiliency to cover that.
> 
>  I think that the sensible way to "probe" is to send "more 
> media/packets" periodically (in bursts)
> (instead of sending garbage as a shield of some sort).
> 
> In all cases I beleive the key is to understand the minimum 
> rate of change of the data/packet rates
> and minimum amplitude of the rate changes, the periodicty of 
> the "probes" etc
> that are required for maintaining a tunable level of 
> "resistance" against TCP traffic.
> 
> So far it seems that only the "factor of 2" has been considered,
> this may seem quite large (too large for a lot of apps and codecs)
> and could make the future of DCCP pretty bleak.
> 
> Let me express my optimistic view as a metaphor:
> 
> To me it looks like the discussion has been a bit like 
> discussing the usage of tires on cars and there would be 2 sides,
> one that is against it and defends that raw steel is good 
> enough (with FEC cushions on the seats !)
> and the other extreme opinion that 2 meters thick balloon 
> tires are what is required for good confort.
> 
> Could the truth be somewhere in the middle ?-)
> 
> 
> Regards,
> 
> 
> Philippe Gentric
> Chief Architect
> Philips Software
> [email-masked]
> http://www.software.philips.com
> 
> 
>                                                               
>                                                               
>                
>                                                               
>                                                               
>                
>                                                        To:   
> "'Phelan, Tom'" <[email-masked]>                        
>                 
>                                                        cc:   
> "[email-masked]'" <[email-masked]>                               
>                 
>                                                         
> "[email-masked]'" <[email-masked]>                             
>                      
>                                                         (bcc: 
> Philippe Gentric/MP4-SUR/CE/PHILIPS)                          
>                
>                "Lars-Erik Jonsson (LU/EAB)"            
> Subject:    RE: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media 
> Guide                      
>                <lars-erik.jonsson@ericsson.                   
>                                                               
>                
>                com>                                    
> Classification:                                               
>                       
>                                                               
>                                                               
>                
>                Sent by:                                       
>                                                               
>                
>                [email-masked]                             
>                                                               
>                
>                                                               
>                                                               
>                
>                25/11/2003 12:52                               
>                                                               
>                
>                                                               
>                                                               
>                
>                                                               
>                                                               
>                
> 
> 
> 
> 
> Tom,
> 
> We do not just have to find ways to get some kind of "fairness"
> between applications, but we actually have two main goals:
> 1) Avoid congestion
> 2) Improve network utilization
> 
> By probing the network, TCP strive for 2), and that is a good
> think. When there is available bandwidth, it is a good thing
> that this resource gets used for actual application data.
> However, sending data just to keep network resources degrades
> goal 2). To me, this seems to be a tricky problem as TCP has
> not at all been designed to interact with real-time streams.
> 
> /L-E
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Phelan, Tom
> > Sent: den 20 november 2003 19:04
> > To: [email-masked]'; Phelan, Tom; 'Rosen, Brian'
> > Cc: [email-masked]'; [email-masked]'; [email-masked]'
> > Subject: [dccp] RE: [AVT] RE: [MMUSIC] DCCP Media Guide
> >
> >
> > Hi Phillipe,
> >
> > The situation I'm worried about is a little different than
> > you describe. Say you have a 10M bps link, over which there's
> > a 4M bps video stream and a long-lived TCP app.  The TCP app
> > will take the remaining 6M bps, and then push for more,
> > which might cause the video stream to lose packets.  The
> > video stream then drops to 2M bps, and the TCP app expands to
> > 8M bps.  This hardly seems fair.
> >
> > The video app can protect itself from this by transmitting
> > enough more than 4M bps to buffer itself against the TCP
> > probes.  In this case we'd come to a relatively steady state
> > where both apps are sending roughly 5M bps.  This seems
> > reasonably fair to me, since the TCP app gets what it would
> > get if it were competing with other TCP apps, and the video
> > app gets to send at its full rate.
> >
> > Tom P.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Tue, 25 Nov 2003 12:20:00 -0800 (PST)

Replies to a couple of related messages, edited:

On Tue, 25 Nov 2003, Greg Herlein wrote:

> > Unfortunately filling the client buffer at a rate faster than
> > the media rate and "when you can" which introduces substancial
> > amounts of time (many seconds) of delay is a technique for
> > media distribution for which DCCP is not needed:
> >
> > It is called "progressive" download, it uses HTTP and it is deployed ...
>
> That's somewhat simplistic, really.  Progressive download has a
> similar effect but it's not controlled, and it's TCP only of
> course.

Yes.  More on the TCP point below.

> For unicast scenarios this kind of thing makes total sense if the
> source is non-real time (ie, streaming from disk).  It's not much
> more than an enhanced jitter buffer, really - you are just adding
> some extra buffer for times when the normal real-time flow is
> impaired, and a mechanism to allow the client to tell the source
> to "fill me up"  and "back it off."  There need not be any extra
> delay at startup, though not doing so creates a window of
> vulnerability.

Exactly right.  Thanks for saving me having to write this.

The point about no additional delay is important: the vulnerability at
startup is no worse than and in fact increasingly less than the
vulnerability for a stream sent constantly at rate 1.

> I'd very much like to see some standardization effort on a
> protocol to support this kind of thing - perhaps an RTCP
> extension?  Perhaps soemthing that can apply to TCP as well?

We talked about doing something like this in RTP itself a few times,
but deferred to congestion control work in other groups.  So DCCP is
now the proposed standardization effort.

> several seconds of buffering is acceptable, correct?

Yes.

> rate, but merely change the instantaneous transmit rate.

Yes.  As I said earlier, you might use FEC to protect against the
probing initially here, same as you could use it to protect an RTP/UDP
stream, but once some buffer is built up for the non-interactive case,
then retransmission is more efficient.

> I'm not clear on how this is better than just using TCP.

The key difference is that TCP insists on 100% reliability.  It must
retransmit a lost packet before any subsequent data can be delivered.
For these media applications, retransmission may still be useful, but
you want the application to have control over the decision to
retransmit or to give up and continue on.

                                                        -- Steve