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

From: "Watson, Mark" <[email-masked]>
Date: Fri, 8 May 2009 15:58:36 -0700

HI Vincent,

Thanks for these comments. I have cut&paste them below and put my responses
inline.

Regards,

Mark

Comments to draft-ietf-fecframe-framework-03 - VR

-------------------------------------------------

For discussion...

1/ Terminology:

---------------

The terminology is not sufficiently well defined and throughout the text we
find several terms for the same concept (I won't list them here). I tried to
compile them below.

At the sender, from top to bottom:
* the application layer provides "Source Transport Data Payloads" through
one or several "Source Data Flow(s)".
* the "Source Transport Data Payloads" are gathered in a "Source Block".
* after the F, L and padding fields have been added to each "Source
Transport
  Data Payload" for the purpose of FEC encoding, the resulting unit of data
  is called the "Source Packet Information (SPI)"
  (NB: this comes from the Raptor I-D).
* from the FEC scheme point of view, we now have "Source Symbols" (i.e., a
  subset of the "Source Packet Information") and "Repair Symbols". They are
  globally called "Encoding Symbols".

* the unit of data containing the source information, plus the "Explicit
  Source FEC Payload ID" (if used), is now called the "FEC Source Packet".
  It is given to the transport protocol.

* the unit of data containing repair information, plus the "Repair FEC
  Payload ID", is now called "FEC Repair Packet". It can contain one or more
  "repair symbols" depending on the FEC scheme. It is given to the transport
  protocol.

We should discuss the above names IMHO...

In particular I'm not satisfied by the "Source Transport Data Payloads"
which follows the transport protocol point of view (payload given to the
transport protocol) rather than what leaves the application layer.
Additionally, it's no longer the transport payload if the "Explicit Source
FEC Payload ID" is appended by the FEC framework.
I suggest: "Application Source Data Units", or simply "Application Data
Units".

MW> The idea was that this is the payload that the application would
otherwise give directly to the transport protocol if the FEC Framework was
not in the way. But Application Data Unit it better, I agree. (I don't think
'Source' is required)

There is also a clash between the "Source Packet Information" and the
"Source Transport Data Payload". The two names should be close to one
another.
I suggest: "Application (Source) Data Unit Information"

MW> Agree

I think that, inside the FEC scheme itself, the usual terminology
(source/repair/encoding symbols) must be used. This is common terminology
with the FEC schemes coming from the RMT WG.

Then we must make sure that the agreed terminology, and only it, is used in
this I-D and others.

2/ Section 6.5. "FEC Framework Configuration Information"
---------------------------------------------------------

I have several comments WRT the pieces of information included in the FFCI.

2.1/ It is said: 
"      1.  Identification of the packet flow(s) carrying FEC Repair
      packets, known as the FEC repair flow(s)."
I think we need more than just an identification. We need to know the
*number* of FEC repair flows for this FEC framework instance and  the
*definition* of each FEC repair flow (e.g., the associated tuple).

MW> Yes, "Identification" was meant in the sense of 'sufficient description
to identify' (i.e. Flow specification) rather than the sense of 'an
identifier'. I think "specification' of the packet flow(s)..." might be
better.

2.2/ It is said:
"        b.  An integer identifier for this flow definition (i.e.
         tuple).  This identifier MUST be unique amongst all source
         packet flows which are protected by the same FEC repair flow."

So, if I follow this text, if a source flow is protected by 2 FEC repair
flows, this source flow can be assigned two different identifiers. This is
a bit strange! I suggest that the identifier be unique among a FEC
framework instance. The drawback I see, however, when this identifier is
encoded in a single byte (e.g. Raptor or R-), is the limited number (256) of
source data flows that can be protected globally. But is 256 really an
issue?

MW> No, each source flow is assigned a single identifier (I can make this
clearer). The uniqueness requirement is that if two source flows are
protected by a single repair flow, then the two source flows must have
different identifiers.

2.3/ It is said:
"     4.  The length of the Explicit Source FEC Payload Id, in bytes"
Why should the length be communicated to the FEC framework instance whereas
the Explicit Source FEC Payload ID is totally defined by the FEC scheme,
whose FEC Encoding ID is provided to the FEC framework?

MW> The purpose of this was to allow receivers that supported the FEC
Framework, but do not support the specific FEC Scheme, to remove the
Explicit Source FEC Payload Id and use the source packets.

3/ Section 8. "Transport protocols"
-----------------------------------

It is said: "The following transport protocols are supported:"
What does "supported" mean, since the framework is relatively independent of
the transport protocol used (it impacts the tuple used to identify flows and
it should preserve the data unit boundaries, but that's all). I'd be in
favor
of having a less directive text, like:

"The FEC framework is compatible with any transport protocol that fulfills
the

 requirements (e.g., in terms of real-time delivery of datagrams) of the
original source data flows. Examples of such protocols include:
  o  User Datagram Protocol (UDP)
  o  Datagram Congestion Control Protocol (DCCP)"

MW> Fine by me!

4/ Section 9.1 "Normative requirements"
---------------------------------------

I do understand and agree with the fact that there is a reasonable limit to
the
repair overhead. However I'm wondering if it makes sense to provide an
actual
figure. This limit depends on the target use-case, and the framework I-D
specifies the architecture, not the use-case.

There is also a potential problem with the current wording:
"   The bandwidth of FEC Repair packet flows MUST NOT exceed the
    bandwidth of the source packet flows being protected."

In complex scenarios, it could result in non desirable limitations. This can
be the case with Fig. 1 of draft-ietf-fecframe-sdp-elements-02:

                                          ____| FEC FRAMEWORK
                                         /    | INSTANCE
                                        /     | 3: Repair Flow
                                       /
                  SOURCE FLOWS        /       | FEC FRAMEWORK
                  0: Source Flow |___/ |------| INSTANCE
              __| 1: Source Flow |            | 4: Repair Flow
             |  | 2: Source Flow
             |                          | FEC FRAMEWORK
             |__________________________| INSTANCE
                                        | 5: Repair Flow
                                        | 6: Repair Flow
                                        | 7: Repair Flow

Admittedly (1) the total bit rate of the 7 repair flows can be lower than
that of the 3 source flows and (2) there are several framework instances.
But this is an example where the section 9.1 limit can be a problem if we
measure the aggregated repair flow bandwidth at the sending host.

I suggest to have a less directive text, like:

The bandwidth of FEC Repair packet flows MUST NOT exceed a certain threshold
of the bandwidth of the source packet flows being protected. This threshold
depends on the use-case where the FEC framework is used. When transmissions
take place over Internet, the bandwidth of the FEC Repair packet flow(s) of
a
single FEC framework instance MUST NOT exceed the bandwidth of the source
packet flow(s).

MW> We have to be careful here. Currently, the framework avoids causing
congestion control problems by specifying this hard requirement that bounds
the repair bandwidth by the source bandwidth. We can then be sure that the
repair bandwidth will be subject to the same congestion control response as
the source flows.

In any case I agree with you, Mark, that using FEC codes in a rateless way
is
definitively useless ;-)

MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a multicast
streaming environment ...

5/ Section 6.2. "Structure of the source block"
-----------------------------------------------

It is said:
"  For each source transport payload included in a source block, the
   following information is provided to the FEC Scheme:
   o  A description of the source transport flow with which the
      transport payload is associated (See 6.5)"

I'd rather provide the "identification" of the source flow. The description
of the flow is provided only once, upon FEC framework instantiation
initialization.

MW> I think this must have been an error. You are right it should be the
identifier defined in the FEC Framework Configuration Information that
should be supplied to the FEC Scheme.

6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id"
----------------------------------------------------------

I don't think that any of the current FEC schemes specifies this
Generic Explicit Source FEC Payload Id. This is a problem...

Besides, how is the 2 byte counter managed? Does it take into account
the source block structure or not? It seems that it is the case, but
it is not clearly said that the counter should be reset to 0 at the
beginning of a new source block.

Additionally, the various FEC schemes can have different maximum source
block sizes which means that the source block structure can differ.
Maybe we should say that all the FEC schemes MUST share the same
source block structure if we want the FEC Source Packets to be shared
between the various FEC schemes.

MW> This was added rather late. The idea was to allow, in principle, for a
source flow to be protected by multiple FEC Schemes without those schemes
having to be aware of each other. But as you say it works only if the
schemes support the Generic Explicit Source FEC Payload Id".

MW> It does not take into account the source block structure, rather the
other way round: the source block structure is constrained by the
requirement that a source block contains a set of packets with contiguous
sequence numbers.

MW> To use this, the FEC scheme essentially has to specify the sequence
number range that makes up a source block in each repair packet for the
block (or in sufficient of the repair packets that it is sufficiently likely
it will be received).

Additional comments:
--------------------

** Current I-D mentions either "Content Delivery Protocol" or CDP.
I suggest to use only CDP throughout of the text.

MW> OK

** Section 6.6. "FEC Scheme requirements"
It is said:
"      ...and the valid packet payload sizes
       (where packet payload refers to the space - not necessarily
       contiguous - within a packet dedicated to carrying encoding
       symbol bytes)."

Sorry, I don't understand "not necessarily contiguous".

MW> I think this was added to accommodate things like RFC2733 and
SMPTE-2022-1 where the repair bytes are stored into a repair packet in a
non-contiguous way (for example repair bytes covering the CC fields of the
RTP headers of the source packets are put into the CC field of the repair
packet.) I agree it is not at all clear. Since these things are not now
being proposed as FEC Schemes, perhaps we should delete the 'not necessarily
contiguous'. 

I also suggest to say:
       "...and the valid transport (e.g., UDP) datagram payload sizes".
(if I understand correctly the goal).

MW> Yes, this would be clearer.

On 4/3/09 5:22 AM, "Vincent Roca" <[email-masked]> wrote:

> Mark, everybody,
> 
> Since the goal was to start a WGLC on the framework document, I anticipated
> a little bit the announce... (sorry if it creates problems).
> Here are my comments.
> 
> Regards,
> 
>    Vincent
>

---

From: Vincent Roca <[email-masked]>
Date: Mon, 11 May 2009 13:08:38 +0200

Hello Mark,

Since we agree for most comments, I only leave below the ones for which
we still need to discuss.

> 1/ Terminology:
[...]

VR: So, to summarize our discussion, here is the current proposal:

* the application layer provides "Application Data Units", through
  one or several "Source Data Flow(s)".

* a certain number of "Application Data Units" are gathered in a
  "Source Block".

* after the F, L and padding fields have been added to each
  "Application Data Unit" for the purpose of FEC encoding, the
  resulting unit of data is called the "Application Data Unit
  Information (ADUI)".
  NB: this comes from the Raptor I-D

* from the FEC scheme point of view, we now have "Source Symbols"
  (i.e., a subset of the "Application Data Unit Information") and
  "Repair Symbols". They are globally called "Encoding Symbols".
  NB: this is in line with the RMT WG terminology used for FEC schemes

* the unit of data containing the source information (i.e., an
  "Application Data Unit") plus the "Explicit Source FEC Payload ID"
  (if used), is now called the "FEC Source Packet". It is given to
  the transport protocol.

* the unit of data containing repair information, plus the "Repair FEC
  Payload ID", is now called "FEC Repair Packet". It can contain one or
  more "Repair Symbols" depending on the FEC scheme. It is given to the
  transport protocol.

Do we agree?

> Then we must make sure that the agreed terminology, and only it, is used in

VR: ...the necessary second step!

> 2/ Section 6.5. "FEC Framework Configuration Information"
[...]
> protected by a single repair flow, then the two source flows must have

VR: Sorry, but I still don't see clearly to what extent the
identifier should be unique in your answer. When you say:
"each source flow is assigned a single identifier", is it
for the whole fecframe instance or not? And the second sentence
of your answer does not clarify this at all.

> Explicit Source FEC Payload Id and use the source packets.

VR: Okay, said this way, it makes sense. You can perhaps clarify
the intent in the original text.

> 4/ Section 9.1 "Normative requirements"

[...]
> repair bandwidth will be subject to the same congestion control response as

VR: I do agree that we need to be careful here.
As already said in section 9, the only goal is to:
     "require at a minimum that the use of this framework
      with any given application, in any given environment,
      does not cause congestion issues which the application
      alone would not itself cause"

The second constraint is for sure needed. But the first constraint
is application/environment specific and no numerical value,
applicable to all possible applications/environments, should be
specified IMHO, unless there is a strong analysis showing this
value is meaningful which I don't see here.
Said differently, why this minimum code rate 0.5 rather than,
for instance, 0.4 or 0.6? Which one is the best value and why?

> is definitively useless ;-)
>

VR: This is however what you are suggesting with the above
requirement which holds no matter the application/environement,
even if the text mentions "bandwidth" rather than "code rates"
(there's a direct mapping between the two concepts).

> 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id"

VR: Okay, I understand the possible way of using the counter.
It should perhaps be clarified in the document if this Generic
Explicit Source FEC Payload Id is to remain.

Regards,

  Vincent

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 11 May 2009 09:30:05 -0700

HI Vincent,

Thanks for your response. Some further comments inline marked 'MW2'. There are perhaps two issues which require discussion/confirmation from the list:
(1) The change in terminology from "Source Transport Payloads" to "Application Data Unit"
(2) The explicit requirement that repair bandwidth must not exceed source bandwidth: I'd especially like to hear from Magnus. I have no objection to relaxing this if the remaining text is likely to be acceptable to the IESG to address the congestion issue, but I am not sure that is the case.

...Mark

On 5/11/09 4:08 AM, "Vincent Roca" <[email-masked]> wrote:

Hello Mark,

[...]

Do we agree?

MW2> We do. I just want to check everyone else is happy with this.

[...]

MW2> Re-reading this, in fact what is stated is equivalent to requiring uniqueness within a framework instance. What is stated is that for each repair flow, every source flow protected by that repair flow must have a different identifier from every other source flow protected by the same repair flow. I.e. Source flows that are to be combined into a single source block must have different identifiers. But a set of source flows that are to be protected together is exactly what characterises a framework instance. I don't think the framework draft limits this flow identifier to 1 byte - though I may have missed that. Certainly the Raptor draft does limit it. I don't think the framework draft needs to provide a limit, but it does need to require that values are allocated from zero upwards.

[...]

MW2> There are many ways rateless codes can be useful. There is only a direct mapping between bandwidth and code rate if you always send all the symbols. So for example there are applications where it is useful to be able to generate many more symbols than you eventually send. In terms of congestion control, it is bandwidth which is the concern, not the rate of the code from which the symbols were taken.

MW2> Sure.

Regards,

  Vincent

---

From: "Luby, Michael" <[email-masked]>
Date: Mon, 11 May 2009 09:55:54 -0700

One input on (2) below: we have customers where limiting the amount of bandwidth allocated for repair to that of the original source stream would be a severe restriction, as the loss conditions they face are much more  than 50% even on average for streaming applications (and thus the bandwidth they need to provide to the repair stream to achieve reasonable quality video streaming is much more than that of the original source stream).  These situations come up in the defense/military, where the senders/receivers are quite mobile, wireless connectivity, and the need for high quality streaming video is paramount.  I would not want to restrict these types of applications from using this framework.

On 5/11/09 9:30 AM, "Watson, Mark" <[email-masked]> wrote:

HI Vincent,

...Mark

Hello Mark,

[...]

Do we agree?

[...]

[...]

MW2> Sure.

Regards,

  Vincent

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 11 May 2009 11:28:38 -0700

> MW2> We do. I just want to check everyone else is happy with this.

I am OK with the definitions here.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Watson,
> Mark
> Sent: Monday, May 11, 2009 9:30 AM
> To: Vincent Roca
> Cc: [email-masked]
> Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-03
> 
> HI Vincent,
> 
> Thanks for your response. Some further comments inline marked ‘MW2’. There are perhaps two
> issues which require discussion/confirmation from the list:
> (1) The change in terminology from “Source Transport Payloads” to “Application Data Unit”
> (2) The explicit requirement that repair bandwidth must not exceed source bandwidth: I’d
> especially like to hear from Magnus. I have no objection to relaxing this if the remaining
> text is likely to be acceptable to the IESG to address the congestion issue, but I am not
> sure that is the case.
> 
> ...Mark
> 
> MW2> Re-reading this, in fact what is stated is equivalent to requiring uniqueness within
> a framework instance. What is stated is that for each repair flow, every source flow
> protected by that repair flow must have a different identifier from every other source
> flow protected by the same repair flow. I.e. Source flows that are to be combined into a
> single source block must have different identifiers. But a set of source flows that are to
> be protected together is exactly what characterises a framework instance. I don’t think
> the framework draft limits this flow identifier to 1 byte – though I may have missed that.
> Certainly the Raptor draft does limit it. I don’t think the framework draft needs to
> provide a limit, but it does need to require that values are allocated from zero upwards.
> 
> 
> 
> MW2> There are many ways rateless codes can be useful. There is only a direct mapping
> between bandwidth and code rate if you always send all the symbols. So for example there
> are applications where it is useful to be able to generate many more symbols than you
> eventually send. In terms of congestion control, it is bandwidth which is the concern, not
> the rate of the code from which the symbols were taken.
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 May 2009 15:33:11 +0200

Watson, Mark skrev:
> (2) The explicit requirement that repair bandwidth must not exceed
> source bandwidth: I’d especially like to hear from Magnus. I have no
> objection to relaxing this if the remaining text is likely to be
> acceptable to the IESG to address the congestion issue, but I am not
> sure that is the case.

Hi,

Catching up on the WG. When it comes to congestion control it is a
required feature for general network usage. Under some circumstances one
can clearly use the framework without congestion control due to
dedicated resources. However, in general one need a mechanism to detect
also failure cases when one has dedicated resources.

I don't have an issue with making it clear that with dedicated/reserved
resources it is acceptable to not have congestion control, although if
possible it is recommended. 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.

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: "Watson, Mark" <[email-masked]>
Date: Wed, 27 May 2009 15:09:55 -0700

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'.

...Mark

On 5/27/09 6:33 AM, "Magnus Westerlund" <[email-masked]> wrote:

Watson, Mark skrev:
> source bandwidth: I'd especially like to hear from Magnus. I have no

Hi,

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 May 2009 10:39:59 +0200

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