Subject: [AVT] RE: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps

From: "Phelan, Tom" <[email-masked]>
Date: Thu, 9 Dec 2004 13:41:11 -0500

Hi Alejandro,

See inline ...

Tom Phelan

> -----Original Message-----
> From: Alejandro Cabrera Obed [mailto:[email-masked]]
> Sent: Thursday, December 09, 2004 11:43 AM
> To: AVT Lista; DCCP Lista
> Subject: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
> 
> 
> Dear people,
> 
> I'm from Argentina, developing a survey about HDTV uncompressed live
> streaming over IP. I'm contacting you in order to know what you think
> about applying TFRC to HDTV uncompressed live streaming (aprox. 1.5
> Gbps), in order to get congestion control.
> 
> 1) Do you think there is any limitation in applying the TFRC mechanism
> to my scenario ???

I think there's two issues you'll need to deal with.  One is slow start - it'll take a good number of round trip times to get up to 1.5G bps.  The other is, what will you do when there is congestion and you must reduce the transmit rate?  I assume you'll be using large packets to get that high a transmit rate, so the small packet issues shown in http://www.phelan-4.com/dccp/tfrc-self-limit.pdf won't be a problem.

> 2) Is it correct the use of RTCP like a feedback mechanism for TFRC,
> taking the RTCP throughput at about 5% of 1.5 Gbps ???

Normally TFRC requires one feedback packet per RTT.  So the RTCP 5% limit is a bit problematic.  The feedback is greater or less than 5% depending on the RTT.  I know this has been raised as a problem the RTP profile for TFRC - I'm not sure how Ladan has dealt with it.  For DCCP, there's no such restriction.  The DCCP feedback packets are fairly small - I don't remember the exact size, but using 40 bytes, you'd need an RTT of less than 5 microseconds to use up 5% of 1.5G on the feedback.

> 
> Maybe, if TRFC is OK to HDTV uncompressed, I'm interesting in studying
> into account the use of LSR and DLSR fields of RR in order to
> calculate the RTT.
> 
> Thanks a lot, I appreciate your opinion.
> 
>  
> Alejandro Cabrera Obed
> 
> _______________________________________________
> 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: Colin Perkins <[email-masked]>
Date: Thu, 9 Dec 2004 19:16:22 +0000

You would also have the issue of how to maintain acceptable viewing 
quality whilst varying the transmission rate. That problem is at least 
as difficult as the practicalities of making the TFRC mechanisms work 
(and note that you must either compress or discard data to do this in 
real-time, so using TFRC for "uncompressed" HDTV isn't practical if 
there might be congestion).

Colin

On 9 Dec 2004, at 18:41, Phelan, Tom wrote:

> I think there's two issues you'll need to deal with.  One is slow 
> start - it'll take a good number of round trip times to get up to 1.5G 
> bps.  The other is, what will you do when there is congestion and you 
> must reduce the transmit rate?  I assume you'll be using large packets 
> to get that high a transmit rate, so the small packet issues shown in 
> http://www.phelan-4.com/dccp/tfrc-self-limit.pdf won't be a problem.
>
> Normally TFRC requires one feedback packet per RTT.  So the RTCP 5% 
> limit is a bit problematic.  The feedback is greater or less than 5% 
> depending on the RTT.  I know this has been raised as a problem the 
> RTP profile for TFRC - I'm not sure how Ladan has dealt with it.  For 
> DCCP, there's no such restriction.  The DCCP feedback packets are 
> fairly small - I don't remember the exact size, but using 40 bytes, 
> you'd need an RTT of less than 5 microseconds to use up 5% of 1.5G on 
> the feedback.
>
>>

---

From: "Ernesto Exposito" <[email-masked]>
Date: Fri, 10 Dec 2004 08:03:25 +1100

Dear all,

However, remember that if for HDTV we have a buffer of some seconds
(following ITU G.1010 standards, we are talking of 5-10 seconds for VoD),
then the results will not be so catastrophic. Indeed, this buffer at the
receiving side could help to hide to the application the effects of
slow-start and transmission variation. TFRC effects are more important for
"interactive" streams.

Best regards,

Ernesto Exposito
NPC Program National ICT Australia Ltd.
Sydney, Australia
Tel: +61 2 8374 5541
Email: [email-masked]
Web: www.nicta.com.au

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin
Perkins
Sent: Friday, 10 December 2004 6:16 AM
To: Phelan, Tom
Cc: DCCP Lista; AVT Lista
Subject: [AVT] Re: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps

Colin

---

From: Alejandro Cabrera Obed <[email-masked]>
Date: Fri, 10 Dec 2004 11:44:31 -0300

Dear people,

In accordance with your right comments about TFRC applied to HDTV
uncompressed streaming, I was thinking in a new point of view in order
to transmit this type of video taking into account the congestion
control. My technical situation is not good enough because I have not
contact with new generation Internet networks, just reading as much
information I can and the support of people like you. So maybe I could
have erroneous concepts…sorry.

I have the following idea: 

- There is an under-emphasized aspect of QoS, which is to provide
better ways for the application to discover the current state of the
network, so that it will not undertake to do the impossible. For
example, the HDTV streaming software could be able to tell the end
user: "Sorry, now you can get only EDTV resolution". And then the end
user can decide whether to playout or not the video streaming.
- I suppose stable congestion conditions and low loss on the network.
- I use jumbograms 9 KB.
- RTP/UDP/IP with RTP payload format for uncompressed video.
- I always run an Iperf session between server and user in order to
get an updated packet loss value. I choose a loss threshold. Before
the user run the streaming application, if loss is less than threshold
I could apply TFRC to the streaming because throughput variation will
be minimum; if loss is equal or greater than threshold I could
dowsampling the color samples from 12 to 10 or 8 bits for example.
- Conclusion: the HDTV is transmitted from sender to user with either
TFRC or color downsampling along a unique streaming session (no mixed
mechanism applied to a same streaming session) in order to adjust the
congestion control.

I really appreciate your comments again because I'm getting my thesis
conclusions.

Thanks a lot, greetings !!!

Alejandro

-- 
Alejandro Cabrera Obed
[email-masked]

---

From: Caitlin Bester <[email-masked]>
Date: Sat, 11 Dec 2004 08:33:38 -0800

> slow-start and transmission variation. TFRC effects are more important for

Which is also true if you were streaming MPEG-2 or some other form
of compressed HDTV.

If you are sending uncompressed HDTV over a short essentially private
network then a bandwidth reservation scheme is more critical than TFRC.
If you are sending 1.5 Gbits over an unknown network that doesn't have
known reservation capabilities then you really need to ask yourself
why you aren't using compression.

As soon as you hit any form of public network the cost of the bandwidth
has to be higher than the cost of the compression. And HDTV 
decompression is designed for consumer products.

The only reason I can think of for sending it uncompressed is to
support editing. Are your video editors really that far from the
signal source?

Congestion control is not my primary area of focuse, but I doubt
that any current algorithms are intended to deal with a sustained
flow that consumes a subtantial portion of each network segment
that it passes through.