Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media dis tribution?

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 3 Dec 2003 09:57:11 -0500

Hi Brian,

>> * Say there's no loss.
>> 
>>   If there's no loss, DCCP and UDP are equivalent, except that DCCP
>>   enforces slow-start.  Slow-start will not matter for 
>> low-rate flows like
>>   most VoIP flows.  It will for higher-rate flows like the 4 
>> Mb/s video
>>   flow Brian Rosen has mentioned.  A TFRC/DCCP flow could probably
>>   slow-start up to 4 Mb/s in 7 or 8 round-trip times, in the 
>> absence of
>>   loss.
> A typical RTT on the internet these days is 50-100 ms.
> If you experience 30% loss in the first 3 RTTs of voice, you will clip
> the "hello" pretty badly.  If it's 7-8 RTTs, you will definitely have
> a very poor experience.

Are you saying that an interactive video session can't afford a
pre-connection training period?  It seems to me that all such systems that
I've used have a several second delay at the start of the connection during
which several things are negotiated.

Voice-only connections have a stricter expectation of post-dial delay, but
the four packets per RTT at the beginning of slow start is almost always
enough for telephony-quality voice, so there is in practice no slow start.

Are you also saying that you expect an app that sends at 4M bps to
immediately change from 0 bps to 4M bps?

Tom Phelan

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 10:53:48 -0500

> which several things are negotiated.
There are indeed a couple of RTTs for signalling and codec 
negotiation.  There could be some ms of codec initialization, then 
data starts full steam. In most video codecs, it's actually worse, 
because you usually start with an I frame, that has the least 
compression.  You end up buffering this away often to force the data 
to be more CBR like.  We don't have this problem.

Our video codec has an 8 frame (~250 ms) start time.  That's around 
2-5 RTTs. The data is flying at the CBR rate right away, but we 
don't display the video until we get around 8 frames into the 
sequence.  If you delay the arrival of the 8 frame @ 4Mbit data, 
we'll have to delay the start of video.  It's already annoying, 
because it's slower than the voice.

> enough for telephony-quality voice, so there is in practice 
What I said was that if you have 30% loss for 4 RTTs and you 
listen to that, you will clip the "hello".  Normally, you send 
RTP at the negotiated rate, and you play what you get.

You could force more buffering before playback, which only 
increases PDD. Increases in PDD are measured in seconds.  
At 100ms, you need 10 RTTs to get an extra second.  That would 
only be interesting if you don't experience loss during this period.
However, there is a hard upper limit.  You can't delay the voice
more than 150 ms mouth to ear.  The codec packetization period
eats up a lot of that (40 ms), and the network eats up a lot
(25-50ms typ one way, but usually you engineer for more). 
You don't get 4 RTTs of jitter buffering, that's for sure.
If you are filling and emptying a buffer at a fixed rate
(less jitter on the network), you can't build some buffer
into the beginning of the stream and expect to bleed it
off later.  Once you have buffered up bits, you are stuck
with that buffer +/- jitter. 

I don't have a lot of experience using TCP on media streams, 
so I'm not really sure what happens in practice.  In UDP, the 
transmitter starts up sending at the fixed, negotiated rate.  
The receiver starts by filling the jitter buffer.  When the 
buffer is "half" full, it starts playing at the fixed, negotiated 
rate. Filling the buffer is part of PDD, and it can cover some 
ugliness in actual arrival rate, but I don't think it covers what 
slow start actually does.  Again, I really don't have enough 
experience to know for sure.  
> immediately change from 0 bps to 4M bps?
Yep; bang! 0 to 4Mbit in two packets.  Actually, there is some 
buffering at both ends in our system, but much less than you expect.  
We spent a LOT of time getting rid of buffering to make it work well.  
The entire video chain has less than 90 ms delay (flash a led in the 
camera, measure it on the screen) including camera and screen sync,
encode/decode and all buffering.  The video delay determines the 
audio delay in order to get lip sync.  This is a very important 
characteristic it turns out, because it allows you to argue :) 
Not every system works like ours, for sure.  Every video codec
I know either has a burst at the beginning at higher than nominal
rate, or has immediate CBR.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 15:23:50 -0500

Yes yes.

Another example is Push-To-Talk

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2003 12:19 PM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; [email-masked]
> Subject: Re: [dccp] Re: [AVT] Would DCCP kill Internet real-time media
> dis tribution?
> 
> 
> Multi-party, non-multicast (central server) conferences should not be 
> forgotten in this discussion. They complicate life in two ways:
> 
> - The penalty of not using silence suppression gets much 
> larger. If you 
> have a conference with 100 participants, a modern 
> implementation would 
> have one or two active inbound stream and 100 outbound 
> (mixed) streams. 
> If applications need to keep sending data to keep their 
> place, suddenly 
> inbound data volume will be multiplied by a factor of between 50 
> (transmitting at half rate) and 100.
> 
> This gets worse for the typical video-follows-audio setup.
> 
> - Similarly, for a useful interactive conference, 
> participants have to 
> be able to interject and speak up immediately, with the video stream 
> following instantaneously. They cannot wait multiple 
> round-trip times as 
> they'll never get a word in edgewise. Thus, there is no masking of 
> ramp-up delays if you want a reasonable user experience.
> 
> (Similar considerations apply to the now very popular push-to-talk 
> services. Trying to sell a service where the user has to 
> push, wait and 
> then talk does not seem like a winning proposition.)
> 
> Masking is also rather tricky for two-party audio. There was a long 
> discussion in the SIP working group on this topic a few years ago, 
> leading to fairly elaborate hand-offs between reservation and session 
> signaling to minimize the post-pickup delay. As soon as I hit the 
> 'accept call' button, I need to be able to say 'hello' and be 
> heard by 
> the other side. The only masking opportunity is to start 
> sending audio 
> data 'to warm up the line' while the phone is ringing, adding more 
> bandwidth consumption for the large number of calls that 
> don't succeed. 
> At $4/MB for mobile voice data, this is unlikely to be 
> popular. (Typical 
> ring-to-answer delays are about 20 seconds; average call 
> durations for 
> mobile are probably three minutes, so this immediately adds about 10% 
> overhead, not counting the 60% or so of calls that fail over to 
> voicemail after 30 seconds.)
> 
> I believe that there now is a suggested initial TCP windows 
> size > 1. Is 
> this correct? (If you figure a maximum acceptable network 
> delay of 100 
> ms and a typical audio/video packet spacing of 50 ms, you would be 
> sending about 4 packets per RTT.)
> 
> 
> Henning
>

---

From: [email-masked]
Date: Thu, 4 Dec 2003 10:58:19 +0100

Rosan you wrote:

>I'm dimly aware of what Philippe is talking about, but I don't
>think it does what the first paragraph above describes today.

have a look at things like:

http://www.nextream-online.com/nextream/documents/pdf/WP%20FLEXTREAM.pdf

the type of rate change these things do is pretty flexible, they actually change the rate
several times *inside one video frame*  and the range of changes can be pretty large.
quality is "tunable" and .... well just switch on your TV and look !

regards,

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Dec 2003 09:08:58 -0500

I think this proves my point.
>I have never heard/seen a codec that can dynamically, in real time,
>vary its rate in response to network conditions in a way that
>is not objectionable to the user.

This product cannot dynamically vary its rate in response to network
conditions.  It appears to vary rates of multiple streams to keep
the aggregate within a fixed rate, which indeed, as you say, may
portend the possibility of dynamically varying the rate in response
to network conditions.  The algorithm, as described, probably is
not suitable for interactive streams, because of delay considerations,
as I suggested might be a concern.

If we had a reasonable amount of experience using techniques such as
this one in real networks, then I might have to change my opinion.
As it stands, this is pretty far from what I would need to
change our product, or to get me to believe that any substantial
part of the VoIP market would deploy such algorithms any time soon.
If you and Eddie want to keep slogging on DCCP for this kind of
codec, please continue, but I'm still in the skeptical stage.

Brian 

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Thursday, December 04, 2003 4:58 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: RE: [dccp] Re: [AVT] Would DCCP kill Internet real-time media
> dis tribution?
> 
> 
> 
> Rosan you wrote:
> 

the type of rate change these things do is pretty flexible, they actually
change the rate
several times *inside one video frame*  and the range of changes can be
pretty large.
quality is "tunable" and .... well just switch on your TV and look !

regards,

Philippe Gentric
Chief Architect
Philips Software

---

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 4 Dec 2003 11:28:46 -0500

Hi Henning,

> sending about 4 packets per RTT.)

The current CCID3 draft (TFRC for DCCP) says the initial rate is 4 packets
per RTT.  This should pretty much eliminate slow start for speech audio.

Your points about the value of silence suppression for non-multicast
conferencing seem bang on target.  I'll remember to keep that in mind.

Tom Phelan

---

From: "Phelan, Tom" <[email-masked]>
Date: Mon, 8 Dec 2003 13:50:36 -0500

Hi Brian,

> In a conference application, streams come and go as different speakers
> come and go.  Even in a centrally mixed conference, which is not
> as demanding as an end-system mixed conference, most participants
> are not talking, and not sending video.  When they start talking,
> the start sending media, voice and video.  To send media all the
> time unnecessarily uses bandwidth; a lot of it.

I guess I've never used more-than-two site video conferencing.  You're
saying that when a site stops talking its video goes dark (or still)?

Tom P.

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 13:59:39 -0500

> I totally agree. Whilst "instant on" is really important [at 
> the application layer] for streaming / VoD applications with 
> trick-modes such as fast-forward, rewind, etc. (don't want 
> buffering every time you want to scan / hop channel etc.) it 
> should be up to the application to provide that type of 
> functionality. It should not be up to the network / transport 
> to cater for this.
Fast forward/rewind functions can probably maintain an existing
stream, or even slow start.  What wouldn't work is channel surfing.
We know from experience that unless this is very fast, it's
a big problem.  The digital cable guys know that even the startup
time of the MPEG codec is a problem for them, let alone additional
delay caused by slow start.  Usually, not all channels are served
from the same server, so channel surfing has to start/stop streams
fast.

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 8 Dec 2003 14:01:59 -0500

Depends on the implementation.

If you have 100 participants, not all of them are on the screen,
only 2-10 or so are.  When one of the participants that are not
on screen start talking, they show up.  Optimized implementations
would not send the video unless you start talking in such a case.
Imagine the effect of 100 participants even at 512K if 1/10 of them
sent video vs all of them.

Brian

> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 1:51 PM
> To: 'Rosen, Brian'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [dccp] RE: [AVT] Would DCCP kill Internet real-time media
> dis tribution?
> 
> 
> Hi Brian,
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 8 Dec 2003 19:57:14 -0500

Brian,

While some service providers may offer various QoS schemes in order to
squeeze extra revenue out of every bit they push, surely for the foreseeable
future there will continue to be providers who do not - who merely offer
best-effort Internet as a commodity. By failing to standardize a responsible
real-time protocol, we in fact encourage the sustained deployment of the
sorts of overlay networks you describe below. While the IETF does not always
see eye-to-eye with the marketplace, we do have a responsibility to offer
the marketplace credible alternatives to replacing the Internet with a
labyrinth of admissions control systems.

While I understand that the '4Megs or bust' philosophy springs from the
admirable goal of providing a consistent user experience, if I owned one of
your videophones (you know, various annual gift-giving holidays are just
around the corner...) I'd still like to be able to use it over my more
modest home office connection. I'd like a device that isn't hardwired to
just shut down if it can't offer me its ideal codec. Congestion control can
offer feedback to the device to help it know the transport-layer rate that
it can practically use, which could in turn influence codec selection, and
so on. The more RSVP-like approach of reserving the optimal amount of
bandwidth also has its place, and the IETF has long since acknowledged the
right of both of these approaches to co-exist, if uneasily. The IETF does
not hold a gun to any vendor's head, forcing them to do either or both.

There are forms of real-time communications that today's best-effort
Internet is unlikely to support in their full glory. But is this seriously
an argument that there is no point in standardizing a congestion control
scheme for unreliable datagrams for use over a best-effort network? That a
protocol instantiating such would have no applicability to real-time
communications?

Jon Peterson
NeuStar, Inc.

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 2:57 PM
> To: [email-masked]'
> Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> Mark
> The reality of networks these days is that plain jane best effort 
> Internet doesn't make much money.  Premium services do.  So the 
> trend, which is clearly not universal, but is pretty obvious, 
> is that SPs are trying to bring new bandwidth users onto their 
> networks where the extra bandwidth is not just more bits, but 
> for which they can charge for service beyond best effort packet.
> 
> Voice is one of those services, and video is one of those 
> services.  You don't see a whole lot of investment these days 
> in plain Internet service, and you do in voice/video over IP 
> networks.  So, while there are pure play best effort operators 
> out there, and they will be there, the money is in the premium 
> services.  Even if an ISP does not directly provide premium 
> services, other SPs will, using the underlying packet carrier
> as the pipe, and the USERS of the premium services will yell 
> loudly if their premium services are not delivering what they 
> pay for.  If a customer of voice/video service gets told that 
> his pipe provider is intentionally degrading his service, what 
> do you think he will do with his pipe business?
> 
> Everyone agrees, I think, the most desirable situation is 
> one in which we have a true converged network, not overlay 
> networks, not separate networks, for these new services.  
> I'm sure that there will be a lot of overlay networks around 
> for quite a while, because we don't have the mechanisms we are 
> discussing here - ways for classic best effort TCP to co-exist 
> well with real time media.  Everyone wins if we figure out good 
> ways for this to happen.  Everyone loses if any SP starts 
> intentionally degrading one kind of service to make another
> kind of service work better.  That's why I don't think it's 
> going to be common to stomp on media OR TCP.  Rather, I think 
> everyone expects us to do our jobs well and make both kinds of 
> streams work well together.
> 
> We aren't going to solve this problem with anything done on one side
> folks; both sides are going to have to have new mechanisms.
> 
> Brian
> 
> > From: Mark Allman [mailto:[email-masked]]
> > Sent: Monday, December 08, 2003 5:02 PM
> > To: Rosen, Brian
> > Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> > Subject: Re: [dccp] RE: [AVT] Would DCCP kill Internet 
> real-time media
> > dis tribution? 
> > 
> > 
> > 
> > Brian-
> > 
> > > And, as I've pointed out, since these kinds of apps represent much
> > > higher revenue per bit that the TCP-type apps, it's much 
> more likely
> > > that the network operators would deploy TCP stompers than media
> > > stompers.  YMMV.
> > 
> > I saw your assertion in response to Sally a while back in 
> this thread.
> > 
> > But, I think we have a disconnect.  I am generally thinking 
> > in terms of
> > best-effort networks (as I think Sally was).  Further, a 
> network that
> > has no priorities or traffic classes, but rather just tries 
> > its hardest
> > to get all the data across.  This is the kind of network where
> > congestion control is important.  And, this is the kind of 
> > network where
> > I think you'll see "stompers" that attempt to surpress 
> flows that are
> > attempting to use a disproportionate amount of the 
> bandwdith (whether
> > that be streaming or mis-behaving TCP or ddos floods or whatever).
> > 
> > Your claim above does not match my model of a best effort network.
> > I.e., if people are willing to pay more for the traffic of some
> > particular app and you provision appropriately then you no 
> longer have
> > just a dumb best-effort network.  If you can engineer a network and
> > provision appropriately then by all means use UDP and go 
> from zero to
> > 4Mbps instantly.  However, I don't see that as supporting the 
> > assertion
> > that DCCP can't be used for streaming across best-effort 
> networks that
> > are not engineered to give different levels of support to different
> > classes of traffic.
> > 
> > allman
> > 
> > 
> > --
> > Mark Allman -- ICIR -- http://www.icir.org/mallman/
> > 
> > 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
> > 
> 
> 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
>

---

From: "Phelan, Tom" <[email-masked]>
Date: Tue, 9 Dec 2003 09:14:34 -0500

Hi Yaakov,

It seems to me that the TDM connection could deal with connection setup
delays caused by a ramp-up period at the beginning of the connection.  The
connection would really begin once the sufficient rate was reached.  Since
after that the transmission would be at constant rate, there wouldn't be any
more start up problems.

Tom Phelan

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2003 9:09 AM
> To: Magnus Westerlund; Rosen, Brian
> Cc: [email-masked]; [email-masked]; Eddie Kohler
> distribution?
> There is another application (other than video, that is)
> that is potentially high-bandwidth and has problems with
> slow-start.
> 
> I am speaking of TDM pseudowires
> (as being standardized in the PWE3 WG).
> 
> One can carry an E1 or T1 (or several of them)
> over the public Internet, although higher rate TDM services
> probably require dedicated networks.
> 
> Not only is TDM an inherent constant rate service,
> it would be difficult to start it at anything other
> than its full rate, since the other side requires the full
> bandwidth for clock recovery, without which nothing works.
> 
> (Although I could imagine a special mechanism that sends the full
> number of packets per second, but partially suppresses packet content
> for the first few seconds.)
> 
> However, I am not sure whether TDM is an important case here
> as the setup or pull-down of a TDM service is not a frequent event.
> 
> Y(J)S
> 
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Dec 2003 09:27:07 -0500

Jon

While I certainly think what I'm doing is something everyone would
really, truly, want to have, I'm certainly aware that won't happen
for some time.  My app is simply a good example of what the long
term future holds.  The near term is more likely the simple voice 
conferencing application that Henning pointed out, and the channel 
surfing app for video (which is usually the better part of a megabit,
or more).

I think that the discussion of who carriers will penalize is not
very fruitful, but I'll keep swinging on those pitches as long as
people conjecture that SPs are motivated more by TCP fairness
than premium traffic revenue.  As I said, I really don't see any
carrier penalizing TCP or UDP unless it gets excessive, in the manner
Henning suggests.  I have long advocated charging for what you
deliver rather than prohibiting/firewalling/protecting-the-network.

I don't foresee a labyrinth of admission control; I see some very
simple mechanisms that will have pretty wide deployment.  What we
are missing for them is the feedback of loss.  I certainly think
that codec selection for current conditions is appropriate, downshifting
(once) depending on conditions is appropriate, keep alives, or
any new kinds of mechanisms that don't destroy the user experience
are fine with me.

I'm happy to work on, and help advocate, newer transports for media
that are better at coexisting with TCP.  However, I think I understand
what is an acceptable user experience and what isn't; I've spent the
better part of the last 4 years studying the effect of these kinds of
decisions on user experience, some of which is directly applicable
to less-than-4Mbit media streams.  I claim that as long as UDP
works, and DCCP doesn't, we aren't going to move apps to DCCP.
Interactive media streams start and stop abruptly, and the codecs
we have are close to constant rate.  You know that.  UDP can deliver
that, the current proposals for DCCP can't.

Brian

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Monday, December 08, 2003 7:57 PM
> To: 'Rosen, Brian'; [email-masked]'

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Dec 2003 10:03:56 -0500

Mangus

> I wasn't thinking of conferencing. I was more thinking of single 
> conversational cases. I agree that the leg from a new sender to the 
> conference focus will be problematic, and every switch would 
> need to do 
> the slow start which would effect the media badly.
I'm pretty sure that a point-to-point only solution is not a solution
even if the incidence of point to point is 100 x more common.

> 
> The reason I think video is different from other media like 
> audio is: at 
> least in a conference application, the amount of bandwidth. 
> You can get 
> high quality voice using for example AMR-WB with a source bit rate of 
> 23.35 kbit/s + IP/UDP/RTP overhead giving a total around 40 kbit/s. 
> While 40 kbit/s video gives either a very small picture or very bad 
> quality. To get a comparable quality in the video with a least a CIF 
> size screen you must go much higher.
Why do you think that the bandwidth matters in this discussion?
While bigger bandwidth causes congestion sooner, you can get congestion
with a 40kbit stream on a 256K uplink pretty easily.  The solution
is not very bandwidth sensitive I think.  Because of the effect
of packetization periods on overall delay, we see that as codec
bandwidth goes up, packet size goes up.  My 4M streams are extreme,
because you reach MTU before you get a big packetization period,
but that is not true with slower video streams.

> Yes, my point was not that it would not look bad initially, 
> my point is 
> that is that it is possible to make the video codec go from a 
> very bad 
> initial quality up to as good as you have bandwidth. In an 
> application 
> that keeps on sending the bad quality is only in the initial start-up.
But that presents a poor user experience; an experience they do not
get on existing transports.  If you degrade the user experience when
using a data network, you won't get many users.

> 
> > Actually, I'm not aware of any conferencing video systems that ramp
> > bandwidth.  The reason is that the codecs are parameterized 
> for a given
> > quality level/bandwidth, and you can't smoothly change the 
> parameters -
> > you set them and restart the codec.  I suspect that you could design
> > a codec to smoothly ramp, but that's not what we have 
> available to us
> > now.  What you do see sometimes is a codec which has a 
> fixed bandwidth
> > but the algorithm itself sends coarse image more often than 
> fine image,
> > and you see that effect on startup.  That is very undesirable, but
> > it exists.
> > 
> 
> I am not surprised that there is no system that does this. As 
> I said in 
> my previous mail it is time for media application developers to leave 
> their heaven of no congestion awareness and start developing things.
You might want to go talk to the chip vendors, as we mostly see
hardware encoders for video applications except for toys.  It's a
chip level problem, not software.

> 
> Regarding the video codecs and their parameter sets. I know 
> that if you 
> need to switch parameter sets it can create problems in some codecs. 
> However I know of least one codec, H.264, that is design and supports 
> the use of multiple parameter sets. Also within a parameter sets the 
> video has rather large differences in possible bit-rates. Even if no 
> person has been using a video codec in the fashion of 
> frequently turning 
> on the bit-rate limit to the control, it is possible.
I don't yet have enough experience with high quality H.264 to confirm
or deny that this is possible.  I haven't seen that, but implementations
are still very new.

> 
> Still the main point I would like to make is: For best effort 
> services, 
> we and the users will probably need to accept that quality 
> can vary or 
> be changed during a session, due to congestion. If one can't accept 
> this, then one must start using resource reservation.
Actually, I don't agree.  I think a combination of admission control
and some new mechanisms on both TCP and UDP-or-replacement can
achieve quite acceptable results without resource reservation mechanisms.

Brian