Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP?

[Colin Perkins <csp at csperkins.org>]

Jim,

On 27 Oct 2004, at 20:17, Jim Kleck wrote:
> The draft-ietf-avt-tfrc-profile-03.txt is specifically restricted to 
> unicast,
> and specifies feedback possibly once per data packet. This can generate
> too much feedback traffic in the case of one-to-one video conferencing
> (which typically operates at 64K - 512K bps). However, this case offers
> a ready feedback path with much less overhead: the data pkts coming 
> from
> the far end. An additional extension to the RTP hdr could possibly add
> the feedback at a small cost. The challenges with this scheme are:
>
> - there is an implicit tie between the Tx and Rx RTP sessions, but in
>  a one-to-one video conference that should not be too hard to formalize
>
> - if the app does not recv any data pkts from the farend for a while 
> then
>  there will be no feedback, that could mean the far end has nothing to 
> send
>  (in which case a noop RTP pkt with the feedback could be specified,
>  see draft-wing-avt-rtp-noop-01.txt, with no worries about using extra
>  bandwidth because the lack of data makes that bandwidth available...
>  or use the suggested Receiver Report extensions), or it could mean 
> that
>  there is some network problem
>
> Does this seem worth further investigation?

It's an interesting idea, but the result is diverging quite far from 
the traditional model of RTP for data transfer, with RTCP providing 
feedback. Ideally, I think we should keep the profile-specific 
extensions to the RTP header as small as possible, keeping this new 
profile as close to standard RTP as we can.

Did you look at DCCP? That should reduce the overheads, since they 
allow ACKs to be piggybacked on data packets.

--
Colin Perkins
http://csperkins.org/


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt