Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-03

From: "Watson, Mark" <[email-masked]>
Date: Tue, 7 Jul 2009 17:09:54 -0700

All,

To try and close on this issue, I would like to propose that the requirement on the repair bandwidth not exceeding the source bandwidth be maintained, unless anyone else can come up with specific text acceptabel to Magnus that explains 'when it is possible to not have it' (in Magnus' words where 'it' is congestion control.)

As with the sister discussion in RMT, it is always possible for users in specific environments to modify the specification for their own purposes, but if they would like to have the RFC endorse that approach then we need to describe those environments and the properties which allow congestion control requirements to be relaxed in the RFC (i.e. Some text needs to be proposed).

...Mark

On 5/28/09 1:39 AM, "Magnus Westerlund" <[email-masked]> wrote:

Watson, Mark skrev:
> Magnus,
>
> What we have (effectively) said is that the use of FECFRAME should not
> make the application less responsive to congestion than it was before
> the FEC flow was added.
>
> You write "For general Internet usage one clearly needs to be congestion
> responsive. It is the WG's responsibility to ensure that you have such a
> mechanism in place.". Now, if all the IETF-standardised protocols that
> might be used as source flows with FECFRAME were congestion responsive,
> we would have no problem: we could always rely on the source flow
> responding to congestion and we require that the repair flow follows the
> source flow.
>
> However, there exist source protocols which are not congestion
> responsive - for example RTP. Are you saying that the FECFRAME group
> needs to provide a congestion-controlled version of RTP before the
> FECFRAME work can be published ? Or that we need to define a generic
> congestion control to be applied to any FECFRAME flows (source + repair
> - there would seem to be no point in having only the repair flow respond
> to congestion). This would seem to be the only way to discharge a
> 'responsibility to ensure that we have such a mechanism in place'.

I wouldn't classify RTP as congestion unresponsive. With RTCP it is
possible to react on a bit longer than RTT timescales. That can at least
prevent congestion collapse. However, SSM deployements makes things more
difficult. For unicast it can clearly work if you implement things,
which has been the major issue with RTP reaction to congestion.

What I want in the architecture document is a discussion of the issues
around congestion control, and when it is possible to not have it. To
make it clear that for certain type of deployment may need more
mechanism that what is available currently.

I would prefer that you had a full solution for all usages, but I am not
going to require it. This is useful stuff and in a number of deployments
this will not be an issue. In others this will need to be taken very
seriously.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ulaş C. Kozat <[email-masked]>
Date: Wed, 8 Jul 2009 09:51:19 -0700

Should not the requirement be on the total consumed bandwidth by the
source and repair flows? If we will keep the requirement that repair
bandwidth not exceeding the source bandwidth be maintained, at least
the following two cases are worthy exceptions:

1. Someone might want to use a non-systematic code that is
delay-efficient under bursty losses. The framework in this case can be
used by effectively setting zero rate for the source flow and only the
repair flow is used to carry non-systematic encoding blocks.

2. When loss rates are extremely high potentially sweeping the source
blocks and we need low rate FEC encoding (as also suggested by Michael
Luby in his earlier message).

Ulas

On Tue, Jul 7, 2009 at 5:09 PM, Watson, Mark<[email-masked]> wrote:
> All,
>
> To try and close on this issue, I would like to propose that the requirement
> on the repair bandwidth not exceeding the source bandwidth be maintained,
> unless anyone else can come up with specific text acceptabel to Magnus that
> explains ‘when it is possible to not have it’ (in Magnus’ words where ‘it’
> is congestion control.)
>
> As with the sister discussion in RMT, it is always possible for users in
> specific environments to modify the specification for their own purposes,
> but if they would like to have the RFC endorse that approach then we need to
> describe those environments and the properties which allow congestion
> control requirements to be relaxed in the RFC (i.e. Some text needs to be
> proposed).
>
> ...Mark
>
>
>> You write “For general Internet usage one clearly needs to be congestion
>> mechanism in place.”. Now, if all the IETF-standardised protocols that
>> responsive – for example RTP. Are you saying that the FECFRAME group
>> – there would seem to be no point in having only the repair flow respond
>> ‘responsibility to ensure that we have such a mechanism in place’.
>
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 12 Jul 2009 02:23:40 -0700

I agree. If congestion control will be imposed, it should be on the total rate consumed by the application, for example. Separation of source and repair flow bitrates does not make much sense for non-systematic codes. 

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulas C.
> Kozat
> Sent: Wednesday, July 08, 2009 12:51 PM
> To: Watson, Mark
> Cc: [email-masked]
> Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-03
>

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 13 Jul 2009 08:59:36 -0700

Ali, Ulas,

I think we discussed this at some length back at the workshop and decided (for better or worse) to consider only systematic codes.

For publication, we need to answer the congestion control question. For systematic codes, there is a fair amount of text already in the document which motivates the proposed restriction and this provides congestion control for the repair stream for any case where the original application has congestion control.

There are of course other ways of providing congestion control – for nonsystematic cases or for applications with lower code rates, but we do not yet have text describing these and it’s not a straightforward question in either case.

Since we were hoping to move forward with publication soon, I think we are at the stage where if the current solution is not acceptable you need to propose a complete alternative that is likely to be acceptable to Magnus and the IESG. Personally, I would prefer to publish the document with the current restricted solution space and work separately on extending that if there is demand.

...Mark

On 7/12/09 2:23 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

-acbegen

> > Ericsson AB ���������������| Phone �+46 10 7148287
> > Färögatan 6 ���������������| Mobile +46 73 0949079