Subject: Re: [Fecframe] Feedback support by the FEC Framework

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 18 Apr 2008 10:09:01 -0700

On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen (abegen) <[email-masked]> wrote:
> Hi everyone,
>
>  Following up with Magnus' email, I would like to get your opinions and
>  suggestions about how the WG should proceed regarding the feedback
>  issue.
>
>  Currently, the framework does not provide any guideline for the receiver
>  end-points about what they should report back to the sender (or another
>  3rd party). The first question is of course whether we should generalize
>  this feedback support and provide the guidelines in the framework draft
>  OR we should leave these issues to the individual FEC schemes and CDPs.
>  (E.g., an FEC scheme may use RTCP machinery to benefit from the receiver
>  reports and RTCP extended reports to provide any level of detailed
>  feedback about the FEC performance and other metrics listed below.)

Using "may" as you describe above should extend the functionality of
the framework without fixing a solution onto all schemes and CDPs.
Any objections to this?

>  If you think the framework should generalize the feedback support and
>  should define the minimal information that will be included in the
>  feedback reports, please make your recommendations.

The protocol team came to consensus that the feedback details would
likely be too scheme-specific to be generalized into the framework. If
you think this is no longer the case please elaborate. Otherwise do
you feel your above "may" statement is enough to open the framework to
your requirements?

>  FYI, this issue came up in the design team meeting in late January. The
>  design team decided to make the feedback support optional (not a MUST
>  but RECOMMENDED). The basic feedback information that - we thought-
>  would be useful was:
>
>  1) Which FEC schemes and/or repair flows are used by which clients
>  2) How useful the repair flows are, what the FEC recovery performance is
>  3) FEC performance variation over time (e.g., in the long term for
>  planning purposes and in the short term for faster adaptation); number
>  of errors in errored blocks, number of errored blocks, number of
>  corrected errors per source block, various histograms.
>  4) Feedback information can also (if applicable) sent back to the sender
>  when all the missing symbols in a source block are recovered, and the
>  sender starts the (early) transmission of the next source block

With the level of discussion we had during the WG meeting I'm quite
surprised that the email discuss afterwards had died off. We need to
finalize these details and move the draft(s) along. Otherwise I
suppose we can assume these guidelines are without opposition and move
along anyway.

PLEASE SPEAK UP.

Thanks,
Greg

>  Please share your comments.
>
>  Thanks,
>  -acbegen
>  _______________________________________________
>  Fecframe mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/fecframe
>
_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Fri, 18 Apr 2008 13:20:01 -0700

Hi Greg,

Regarding the usage of RTCP, I believe RTCP provides a good feedback
mechanism to report the performance of any FEC scheme that is willing to
use RTP as the transport protocol. RTCP has the built-in receiver
reports that are quite general and useful, but it also supports extended
reports where a new report type can be proposed to carry scheme-specific
feedback. 

As many media flows will be carried over RTP, using RTCP for this
purpose is straightforward. I suggest folks who are not familiar with
RTP/RTCP to refer to Ulas' earlier email about a presentation given in
the AVT group.
http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf 

For non-RTP flows (source or repair), there is not such a common tool
that can be used to provide feedback on the repair performance. I have
not seen any proposal on this in the email list. If the framework will
support only UDP-based flows, we either need to come up with something
similar to RTCP or simply ignore the feedback issue. 

Regarding your second comment, RTCP receiver reports are general enough
to provide some feeback on any FEC flow that is carried over RTP. If
detailed, specific feedback is required by an FEC scheme, extended
reports are the way to go. If framework supports RTP/RTCP, this issue
will be resolved right a way.

Magnus wanted us to discuss this on the list, so let's discuss! We need
to forward this discussion.

-acbegen

> -----Original Message-----
> From: Greg Shepherd [mailto:[email-masked]] 
> Sent: Friday, April 18, 2008 10:09 AM
> To: Ali Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [Fecframe] Feedback support by the FEC Framework
> 
> >  Following up with Magnus' email, I would like to get your opinions 
> > and  suggestions about how the WG should proceed regarding the 
> > feedback  issue.
> >
> >  Currently, the framework does not provide any guideline for the 
> > receiver  end-points about what they should report back to 
> the sender 
> > (or another  3rd party). The first question is of course whether we 
> > should generalize  this feedback support and provide the 
> guidelines in 
> > the framework draft  OR we should leave these issues to the 
> individual FEC schemes and CDPs.
> >  (E.g., an FEC scheme may use RTCP machinery to benefit from the 
> > receiver  reports and RTCP extended reports to provide any level of 
> > detailed  feedback about the FEC performance and other 
> metrics listed 
> > below.)
> 
> Using "may" as you describe above should extend the 
> functionality of the framework without fixing a solution onto 
> all schemes and CDPs.
> Any objections to this?
> 
> The protocol team came to consensus that the feedback details 
> would likely be too scheme-specific to be generalized into 
> the framework. If you think this is no longer the case please 
> elaborate. Otherwise do you feel your above "may" statement 
> is enough to open the framework to your requirements?
> 
> >  FYI, this issue came up in the design team meeting in late 
> January. 
> > The  design team decided to make the feedback support 
> optional (not a 
> > MUST  but RECOMMENDED). The basic feedback information that - we 
> > thought-  would be useful was:
> >
> >  2) How useful the repair flows are, what the FEC recovery 
> performance 
> > is
> >  4) Feedback information can also (if applicable) sent back to the 
> > sender  when all the missing symbols in a source block are 
> recovered, 
> > and the  sender starts the (early) transmission of the next source 
> > block
> 
> With the level of discussion we had during the WG meeting I'm 
> quite surprised that the email discuss afterwards had died 
> off. We need to finalize these details and move the draft(s) 
> along. Otherwise I suppose we can assume these guidelines are 
> without opposition and move along anyway.
> 
> PLEASE SPEAK UP.
> 
> Thanks,
> Greg
>

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 18 Apr 2008 19:04:52 -0700

>  similar to RTCP or simply ignore the feedback issue.

..or modify the framework to allow either UDP or RTP flows. Is that reasonable?

Greg

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Fri, 18 Apr 2008 19:16:23 -0700

Assuming that we modify the framework to allow UDP and RTP, we can use
RTCP machinery for providing feedback for the RTP-based flows. But, what
about the UDP-based flows? Shall we ignore the feedback support for
those or let the individual schemes figure out what to do, which IMHO
may lead to some complications? 

However, I am all ears to hear any ideas.

-acbegen 

> Sent: Friday, April 18, 2008 7:05 PM
> To: Ali Begen (abegen)
> Cc: [email-masked]
> > mechanism to report the performance of any FEC scheme that 
> is willing 
> > to  use RTP as the transport protocol. RTCP has the 
> built-in receiver  
> > reports that are quite general and useful, but it also supports 
> > extended  reports where a new report type can be proposed to carry 
> > scheme-specific  feedback.
> >
> >  Regarding your second comment, RTCP receiver reports are general 
> > enough  to provide some feeback on any FEC flow that is 
> carried over 
> > RTP. If  detailed, specific feedback is required by an FEC scheme, 
> > extended  reports are the way to go. If framework supports 
> RTP/RTCP, 
> > this issue  will be resolved right a way.
> >
> >  Magnus wanted us to discuss this on the list, so let's discuss! We 
> > need  to forward this discussion.
> >
> >  -acbegen
> >
> >
> >
> >
> >  > From: Greg Shepherd [mailto:[email-masked]]  > Sent: Friday, 
> > April 18, 2008 10:09 AM  > To: Ali Begen (abegen)  > Cc: 
> > [email-masked]  > Subject: Re: [Fecframe] Feedback 
> support by the 
> > FEC Framework  >  > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen 
> > (abegen)  > <[email-masked]> wrote:
> >  > > Hi everyone,
> >  > >
> >  > >  Following up with Magnus' email, I would like to get your 
> > opinions  > > and  suggestions about how the WG should proceed 
> > regarding the  > > feedback  issue.
> >  > >
> > > > receiver  end-points about what they should report back 
> to  > the 
> > sender  > > (or another  3rd party). The first question is 
> of course 
> > whether we  > > should generalize  this feedback support 
> and provide 
> > the  > guidelines in  > > the framework draft  OR we should leave 
> > these issues to the  > individual FEC schemes and CDPs.
> > > > receiver  reports and RTCP extended reports to provide 
> any level 
> > of  > > detailed  feedback about the FEC performance and other  > 
> > metrics listed  > > below.)  >  > Using "may" as you describe above 
> > should extend the  > functionality of the framework without 
> fixing a 
> > solution onto  > all schemes and CDPs.
> >  > Any objections to this?
> >  >
> >  > >  If you think the framework should generalize the feedback  > 
> > support and  > > should define the minimal information that will be 
> > included in the  > > feedback reports, please make your 
> > recommendations.
> >  >
> >  > The protocol team came to consensus that the feedback details  > 
> > would likely be too scheme-specific to be generalized into  > the 
> > framework. If you think this is no longer the case please  > 
> > elaborate. Otherwise do you feel your above "may" statement  > is 
> > enough to open the framework to your requirements?
> >  >
> >  > >  FYI, this issue came up in the design team meeting in late  > 
> > January.
> > optional 
> > (not a  > > MUST  but RECOMMENDED). The basic feedback information 
> > that - we  > > thought-  would be useful was:
> >  > >
> >  > >  1) Which FEC schemes and/or repair flows are used by which 
> > clients  > >  2) How useful the repair flows are, what the FEC 
> > recovery  > performance  > > is  > >  3) FEC performance variation 
> > over time (e.g., in the long  > term for  > > planning 
> purposes and in 
> > the short term for faster  > adaptation); number  > > of errors in 
> > errored blocks, number of errored blocks, number of  > > corrected 
> > errors per source block, various histograms.
> >  > >  4) Feedback information can also (if applicable) sent back to 
> > the  > > sender  when all the missing symbols in a source 
> block are  > 
> > recovered,  > > and the  sender starts the (early) 
> transmission of the 
> > next source  > > block  >  > With the level of discussion we had 
> > during the WG meeting I'm  > quite surprised that the email discuss 
> > afterwards had died  > off. We need to finalize these 
> details and move 
> > the draft(s)  > along. Otherwise I suppose we can assume these 
> > guidelines are  > without opposition and move along anyway.
> >  >
> >  > PLEASE SPEAK UP.
> >  >
> >  > Thanks,
> >  > Greg
> >  >

---

From: [email-masked]
Date: Sat, 19 Apr 2008 05:00:34 +0200 (CEST)

If you need for your UDP flows a feedback channel with all the
characteristics of RTCP, why don't you simply set up one (without having
an active RTP flow?  Where is it written that the RTP channel has to send
any data, ever?

Or, you could design an RTP payload format for "Fecframe error control
information" (conveyed in RTP).  Then you even have the chance to control
your control channel :-)

Stephan

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 19 Apr 2008 10:49:18 -0400

> an active RTP flow?  Where is it written that the RTP channel has to  

The receiver finds sender information from sender reports. Would the  
source send out a sender report and give itself a SSRC for a UDP only
session ? If not, I don't see how this would work. If so, a non-aware  
RTP receiver would report no data found, which might mess
up the statistics (i.e., the SR's and RR's might need a flag to say,  
this data is for a non-RTP UDP only session).

The RTCP bandwidth (rtcp_bw) would need to be set to something  
suitable, which implies that the
session bandwidth is set suitably (i.e., to the UDP flow, not to the  
non-existent RTP flow).

There might also be security issues about this (e.g., what if a  
malicious user or misconfigured source starts an RTP flow in what is  
intended
to be a null flow ? How do we tell RTP receivers to ignore this ?)

Regards
Marshall

---

From: David R Oran <[email-masked]>
Date: Sun, 20 Apr 2008 11:34:08 -0400

>> an active RTP flow?  Where is it written that the RTP channel has to
It doesn't, but the the conventional RTCP instrumentation is fairly  
closely tied to the underlying data transport being RTP. Things like  
SSRCs and SDES for describing sources, sequence numbers for  
correlating the reports to the data packets, etc. I suppose it would  
be possible to use the RTCP *framework* for reporting on non-RTP  
flows, but it would seem to still require a new set of RTCP reports,  
one per FEC scheme. Is that what you had in mind?

> session ? If not, I don't see how this would work.
That part would likely work, but we're already stretching the  
semantics even taking about SSRCs for non-RTP flows.

> If so, a non-aware
I think that's the tip of the iceberg...

> session bandwidth is set suitably (i.e., to the UDP flow, not to the
Yup, that part doesn't seem the hard piece.

> to be a null flow ? How do we tell RTP receivers to ignore this ?)
Well, we can protect the RTCP part with SRTCP. I don't see how you can  
prevent malicious senders from sending anything they way, so from that  
point of view I'm not sure what the new problem is. If the  
encapsulation announced in SDP is not the encapsulation sent, the  
problem exists, right?

Another issue may/will be port multiplexing. There's a well-defined  
port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/RTCP  
that could be quite difficult - you'd need a per-FEC scheme  
multiplexing specification.

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 20 Apr 2008 11:42:42 -0400

> one per FEC scheme. Is that what you had in mind?

To me, upon reflection, I don't think that FECFRAME should be doing  
this. If we (or anyone else) really needs to be able to treat UDP  
flows in RTP with RTCP
feedback, this seems like it should be a separate RFC coming out of  
AVT. There are too many possible worms in this can for us to handle it  
just
as an aside.

Regards
Marshall

> Well, we can protect the RTCP part with SRTCP. I don't see how you  
> can prevent malicious senders from sending anything they way, so  
> from that point of view I'm not sure what the new problem is. If the  
> port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/ 
> RTCP that could be quite difficult - you'd need a per-FEC scheme

---

From: "Greg Shepherd" <[email-masked]>
Date: Sun, 20 Apr 2008 09:09:34 -0700

>  AVT. There are too many possible worms in this can for us to handle it

Which part, Marshall? What is being discussed here are possibilities,
not requirements. This last issues is whether we can/should protect
non-RTP flows with RTCP - which I feel is a bit off of the original
question.

The question I posed was whether the framework can support BOTH UDP
and RTP as a transport for the repair symbols. And IF so, then it
would seem those wanting RTCP feedback should opt for RTP for the
transport and NOT UDP.

Greg

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 20 Apr 2008 12:26:28 -0400

On Apr 20, 2008, at 12:09 PM, Greg Shepherd wrote:

> On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks <[email-masked] 
> > wrote:
>>
>>>>> an active RTP flow?  Where is it written that the RTP channel  
>>>>> has to
>>>>> send
>>>>> any data, ever?
>>>>

I was reacting (without any hat on)
specifically to Stephan's idea of using RTCP as a feedback mechanism  
for UDP only flows.

> would seem those wanting RTCP feedback should opt for RTP for the

Indeed. If you want RTCP feedback, use RTP.

Regards
Marshall

>>>>>> Assuming that we modify the framework to allow UDP and RTP, we  
>>>>>> can
>>>>>> use
>>>>>> RTCP machinery for providing feedback for the RTP-based flows.  
>>>>>> But,
>>>>>> what

---

From: [email-masked]
Date: Sun, 20 Apr 2008 21:12:16 +0200 (CEST)

Hi Marshall,

>[...]

> Indeed. If you want RTCP feedback, use RTP.

No. (To the logic expressed in the sentence, but perhaps not to the one
implied.)

I consider it foolish and architecturally unsound to place something that
works perfectly well over UDP into RTP, just to be able to use RTCP.  RTP
has a certain functionality, much of which is not needed to convey the
information needed for fecframe.  And, RTP has overhead associated with
it, that you don't need.  Think of some of the applications of fecframe,
please.  Overhead counts.  (And yes, I know there is rohc.)

Can someone explain to me, how (for example) payload type, marker bit,
timestamp, ssrc, relate to fecframe data?  I buy the sequence number :-)

If there were a solid justification beyond the use of RTCP, I would
probably buy the fecframe-in-RTP argument.

Stephan

>[...]

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 21 Apr 2008 07:33:32 +0200

Hi

Haven't followed this topic fully so my response may not be relevant,
anyway as I understand the subject you may consider a look at DCCP
rather than UDP. 
Surely DCCP has its issues, but as it contains both timestamp and also
support for different congestion control mechanisms there is not need
for RTCP like mechanisms AFAIK. 
Another interesting protocol may be SST
(http://pdos.csail.mit.edu/papers/sst:sigcomm07.pdf) but this is more a
research level project, still worth a closer look.

Regards
Ingemar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: den 20 april 2008 21:12
To: Marshall Eubanks
Cc: [email-masked]
Subject: Re: [Fecframe] Feedback support by the FEC Framework

Hi Marshall,

>> On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks 
>> <[email-masked] Which part, Marshall? What is being discussed 
>> here are possibilities, not requirements. This last issues is whether

>> we can/should protect non-RTP flows with RTCP - which I feel is a bit

>> off of the original question.
>>

I consider it foolish and architecturally unsound to place something
that works perfectly well over UDP into RTP, just to be able to use
RTCP.  RTP has a certain functionality, much of which is not needed to
convey the information needed for fecframe.  And, RTP has overhead
associated with it, that you don't need.  Think of some of the
applications of fecframe, please.  Overhead counts.  (And yes, I know
there is rohc.)

Stephan

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Tue, 22 Apr 2008 14:39:25 -0700

Hi Stephan,

There are certain advantages for using RTP encapsulation for the repair
flows. Based on the discussion, I believe the framework will support
both UDP and RTP-based repair flows. I think nobody objects that.
Anybody?

For those who want to use RTP for the repair flows, IMO a 12-byte
overhead is reasonably OK for 1500-byte packets. The ability of using
RTCP itself may be enough reason for this overhead. 

The discussion over the last few days is good but I am afraid I did not
get the answer I was hoping for. The original question was:

	What is the right/suitable feedback mechanism for UDP-based
repair flows in the framework?

Current direction shows that UDP-based repair flows will not be using a
common feedback framework.

-acbegen

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, April 20, 2008 12:12 PM
> To: Marshall Eubanks
> Cc: [email-masked]
> I consider it foolish and architecturally unsound to place 
> something that works perfectly well over UDP into RTP, just 
> to be able to use RTCP.  RTP has a certain functionality, 
> much of which is not needed to convey the information needed 
> for fecframe.  And, RTP has overhead associated with it, that 
> you don't need.  Think of some of the applications of 
> fecframe, please.  Overhead counts.  (And yes, I know there is rohc.)
> 
> Can someone explain to me, how (for example) payload type, 
> marker bit, timestamp, ssrc, relate to fecframe data?  I buy 
> the sequence number :-)
> 
> If there were a solid justification beyond the use of RTCP, I 
> would probably buy the fecframe-in-RTP argument.
> 
> Stephan
> 
> >[...]
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Apr 2008 17:35:46 +0200

> common feedback framework.

Hi, (as individual)

I think there are some architectural considerations here for the 
framework in regards to feedback mechanisms. Especially with a mix of 
flows. I personally didn't think about this issue at all at the point of 
chartering the WG. I think it would be good to have a generic mechanism. 
However, I don't know if there is enough energy in the WG to take this 
on currently.

To me it seems that some thinking on the architecture for how this can 
be implemented as part of the transport for the framework could ensure 
that there are sufficient room for future extensions into this area if 
enough interest exist.

When it comes to RTP and RTCP I am a believer that FEC in the RTP 
payload formats (as has so far been done in RTP) has one real short 
comming in that it does not cover the RTCP traffic from the sender to 
the client. This becomes relevant in any environments where the packet 
loss rate is a bit higher due to that simple repetition of RTCP suddenly 
aren't enough. So you get perfect or close to perfect media delivery but 
lose a significant part of control traffic from the sender. Quite 
relevant in RTCP SSM usage or when other interesting extensions are in 
use. Sure, this becomes less relevant if ones reason for using FEC is to 
move from <0.5% loss to <10E-6 frame losses to ensure quality.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------