Subject: [FECFRAME-PROTO] Update of FECFRAME draft

From: Mark Watson <[email-masked]>
Date: Thu, 01 Nov 2007 15:09:37 -0700

All,

I updated the framework draft based on my notes from our meeting. I¹m not
sure I ever saw any minutes from that meeting  perhaps I missed them  but
there are probably things I missed as a result.

See you all Monday.

...Mark

_______________________________________________
FECFRAME-PROTO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/fecframe-proto

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Thu, 1 Nov 2007 15:16:50 -0700

Hi Mark,
 
thanks, I will try to read the draft before the meeting.
 
I will also send out the SDP draft to the group before the meeting so
everybody can have a look.
 
I'll setup the conf call tomorrow. You should receive the instructions
at that time.
 
-acbegen

________________________________

	From: Mark Watson [mailto:[email-masked]] 
	Sent: Thursday, November 01, 2007 3:10 PM
	To: [email-masked]
	Subject: [FECFRAME-PROTO] Update of FECFRAME draft

	All,
	
	I updated the framework draft based on my notes from our
meeting. I'm not sure I ever saw any minutes from that meeting - perhaps
I missed them - but there are probably things I missed as a result.
	
	See you all Monday.
	
	...Mark

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 2 Nov 2007 09:41:36 -0700

Mark,

Are you waiting on feedback and/or the monday meeting before
resubmitting the framework draft?

Greg

On 11/1/07, Ali Begen (abegen) <[email-masked]> wrote:
> I'll setup the conf call tomorrow. You should receive the instructions at
> that time.
>
> -acbegen
>
>
> I updated the framework draft based on my notes from our meeting. I'm not
> sure I ever saw any minutes from that meeting – perhaps I missed them – but

---

From: Mark Watson <[email-masked]>
Date: Fri, 02 Nov 2007 10:50:32 -0700

I thought the idea was to discuss at the Monday meeting and then submit - I
can submit now though if people prefer and then re-submit after the Monday's
meeting.

...Mark

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 2 Nov 2007 13:57:18 -0400

I am also of opinion to discuss the ID on Monday, make necessary
changes, and then submit it.

Cheers,
Rajiv 

> -----Original Message-----
> Sent: Friday, November 02, 2007 1:51 PM
> To: Greg Shepherd; Ali Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [FECFRAME-PROTO] Update of FECFRAME draft
> 
> meeting. I'm not
> >> sure I ever saw any minutes from that meeting - perhaps I 
> missed them - but

---

From: "Greg Shepherd" <[email-masked]>
Date: Fri, 2 Nov 2007 11:14:22 -0700

Just confirming status. ADs were under the impression that we were not
making progress. ;-)

Thanks,
Greg

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 5 Nov 2007 00:15:41 -0500

Hi Mark,

Please consider few comments to ietf-fecframe-framework-01-draft.html
(well written, btw). The important ones are 10, 18, 20, 28, 29, 31, 33
and 36.

1) Page1 - Abstract - ..applications in the internet to provide
protection...

==> Perhaps, we should say "public or private" data networks instead of
limiting ourselves to the internet.

2) Page 1 - Abstract -  ...forward error correction (FEC)...

==> FEC is shown as the shortened form of Forward error correction,
whereas FEC is defined as forward erasure correction in section 2.  

Should we use one or the other throughout the draft for the sake of
consistency?

3) Page 1 - Abstract - ...inteded for streaming media.

==> Why only streaming media? Perhaps, remove 'streaming' word.

For example, A lot of Cable MSO providers define streaming TV
differently from the broadcast TV. Just a taxonomy game!

4) Page 2 - Section 1 - .......primary examples are media streaming
applications..

==> Same as #3. Perhaps, remove streaming.

5) Page 3 - Section 1 - ..expected to be common to all Content ..

==> ..expected to be crucial (and likely common) to all content...

6) Page 4 - Section 2

==> It is worthwhile to include the CDP definition.
==> The following terms are actively used, but not quite defined here -
'FEC repair data', 'FEC repair packet payload', 'FEC repair packet',
'FEC source packet'.

7) Page 4 - Section 4 - .. and possibly also a Diffserv ..

==> We should make DSCP inclusion OPTIONAL.

8) Page 5 - Section 4 - last para - .. Specification as described below.

==> Did you mean to say 'described in the subsequent sections'?? 

9) Page 6 - Section 5.1 - 1st para - .. supported transport protocol..

==> Perhaps, provide the list of protocols or refer to the appropriate
section that contains such list.

10) Page 6 - Section 5.1

==>  This section deserves illustrating the logical sequence of source
operation and receiver operation respectively. Perhaps, two separate
figures can help a lot. 

11) Page 6 - Section 5.1 - 2nd para

==> This section seems to be consistent in using either 'repair packet
payload' (see bullets) or 'repair data'. We may prefer the former, IMHO.

11) Page 6 - Section 5.1 - 3rd para

==> Part of the 3rd para is not quite clear. Perhaps, the following
could be considered as the replacement -
 
The FEC framework then perofrms two operations - (i) It appends the FEC
payload IDs, if provided, to each of the source packets, and sends the
resulting packets, known as 'FEC source packets', to the receiver. (ii)
It places the provided 'FEC repair packet payloads' and corresponding
'FEC FEC Payload IDs' appropriately to construct 'FEC repair packets'
and send them to the receiver. Please note that FEC repair packets are
sent......<<rest follows>>

12) Page 6 - Section 5.1 - 5th para 

==> Please start the 5th para with "At the reciever..." for better
readability. The 2nd para uses "At the sender" already. 

13) Page 6 - Section 5.1 - 5th para - ..including their FEC Payload IDs
to..

==> What if the FEC source packet didn't include the FEC payload IDs? 

14) Page 6 - Section 5.1 - 5th para - ..FEC Scheme for decoding.

==> Would the decoding be performed, if there wasn't any source packet
loss ?? If no, then the related sentence needs rephrasing.

15) Page 6 - Section 5.1 - 6th para - ..source block have been lost..

==> Perhaps, it is desirable to clarify here how is this loss dectected
by the receiver, or provide the reference to another section.

16) Page 6 - Section 5.1 - 6th para  - ..may perform FEC decoding to
recover ..

==> Please clarify - Decoding of what?? FEC source packet? 

17) Page 7 - Section 5.1 - 8th para and 9th para 

==> Please consider placing 8th and 9th para under a new sub-sections
with the title of new field(s) defined in these paras. 

18) Page 7 - Section 5.1 - 8th para - ..called the encoded Source FEC
Payload ID field..

==> I don't quite see the need for defining another term - "encoded
source FEC payload ID". How is it different from the 'Source FEC Payload
ID' field? Do we loose anything if we call the field the same as what it
carries.

	AFAIK, the field carrying the 'Repair FEC Payload ID' is called
FEC Payload ID' field. So, the same could be adopted in the above case.
Consistency again!!

19) Page 7 - Section 5.2 -  

==> Shouldn't there be another bullet between 2 and 3 that says FEC
scheme returns XYZ for the sake of completeness?? 

20) Page 7 - Section 5.2 - 3rd bullet -

==> The FEC framework is defined to be in between the Layer4 and Layer7.
So, how does the layer3 get involved (as per the text in bullet#3) when
the processing is local to the FEC framework which sits above layer4 ??

	Perhaps, a figure would be helpful to avoid confusion.

If we imagine an endpoint equipped with the Source FEC functionality,
then the IP (layer3) and port# (layer4) addresses are _not_ known at the
FEC layer. 

Also, the CDP may not even have conveyed the IP addresses, hence, citing
CDP to provide the IP address shouldn't be mentioned.

21) Page 7 - Section 5.2 - 2nd bullet -

==> What we should consider conveying is that - The 'Source FEC payload
ID' is encoded in either a separate field or conveyed via an existing
field. 

22) Page 8 - Section 5.2 and 5.3 -

==> Do we still need to differentiate repair packet payload from repair
data?

23) Page 8 - Section 5.3 - Bullet 1 

==> The FEC source packet is received 'by who'? Please clarify.

24) Page 8 - Section 5.3 - Bullet 2

==> The FEC repair packet is received 'by who'? Please clarify.
==> In "" ..FEC Payload ID field are passed ..."", passed by who??
Please clarify.

25) Page 8 - Section 5.3 - Bullet 4 - ..received for a source block...

===> Should it be "..received for the same source block..."?

26) Page 8 - Section 5.3 - Bullet 5 - ..source data to a FEC
framework...

==> This is the first time "FEC framework" is mentioned in this section.
Perhaps, also mention it previos bullets.
==> Bullet 5 is also listed as bullet 4. Just a typo.

27) Page 9 - Section 6.2 - Bullet 1 

===> How are we defining the identity here? IP or UDP or both? Or the
Tuple?
	In either case, comment#20 applies here as well. 

28) Page 9 - Section 6.2 

==> It may be a good idea to explicitly consider the following two cases
-
	(a) FEC functionality is on the endpoint
	(b) FEC functionality is _not_ on the endpoint

In case of (b) the FEC layer should already know the identity (IP and
Port#) of the flow. But in case of (a), it is not so.

29) Page 9 - Section 6.3 

==> We need to sort out the following -
i)  Where/hos is the checksum calculated?
ii) What if the IP MTU is exceeded (after appending the Source FEC
payload ID to the original source IP packet)?
Iii) Does the receiver need to know whether the source FEC payload ID is
encoded in the packet in a separate field or not i.e. conveyed using
existing field(s)? 

30) Section 6.3 and 6.4

==> The figures drawn are the reverse of Fig 1. Perhaps, can be udpated.

31) Page 10 - Section 6.3 - last para 

==> What we should consider saying is that - The 'Source FEC payload ID'
is encoded in either a separate field or conveyed via an existing
field(s) in the IP header.

32) Page 10 - Section 6.4 - 2nd para - ..operation of the FEC algorithm.

==> Would it be better to say - "..operation of the FEC algorithm at the
receiver?"

33) Page 11 - Section 6.5 - 2nd para - ..includes identification of a
number of packet flows.

==> Why do we need to identify the # of packet flows? Perhaps, needs
rephrasing.

36) Page 12 - Section 6.5 - list

==> Should we need to include the following to the config information?
	- Source FEC Payload ID
	- Size of the Source Block
	- Repair FEC Payload ID

37) Page 13 - Section 8 - ...We propose a third approach, which is to
require...

==> Where are the other two approaches discussed?

~~~~~~~~~~~~~~~~~~~~

Cheers,
Rajiv

> Sent: Thursday, November 01, 2007 6:10 PM
> meeting. I'm not sure I ever saw any minutes from that 
> meeting - perhaps I missed them - but there are probably 
> things I missed as a result.
> 
> See you all Monday.
> 
> ...Mark
> 
>

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Fri, 9 Nov 2007 15:00:26 -0800

from Section 5.2:
 
--> The port(s) and multicast group(s) to be used for FEC Repair packets
are defined in the FEC Framework Configuration Information.
 
I don't think this is part of the configuration information. It is part
of the SDP but not the configuration information. 
 
It is a media-level attribute and it is not related to FEC. 
 
Any ideas why we have such a statement?
 
-acbegen

	All,

	See you all Monday.
	
	...Mark

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 10 Nov 2007 19:24:47 -0500

Hi Ali,

While it is true that the IP/port is not related to the FEC
functionality, but it is one of the most important information, without
which the FECed packets may not even be recognized. IMO, the IP add and
port are indeed part of the config info. 

This must be specified by the device formulating the repair packets and
conveyed to the remote device. How is this encoded is a separate matter.
Of course, in this context, SDP is utilized for the encoding.

Cheers,
Rajiv

> From: Ali Begen (abegen) 
> Sent: Friday, November 09, 2007 6:00 PM
> To: Mark Watson; [email-masked]
> Subject: RE: [FECFRAME-PROTO] Update of FECFRAME draft
> 
> from Section 5.2:
>  
> --> The port(s) and multicast group(s) to be used for FEC 
> Repair packets are defined in the FEC Framework Configuration 
> Information.
>  
> I don't think this is part of the configuration information. 
> It is part of the SDP but not the configuration information. 
>  
> 	I updated the framework draft based on my notes from 
> our meeting. I'm not sure I ever saw any minutes from that