Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05

From: Greg Shepherd <[email-masked]>
Date: Wed, 14 Apr 2010 10:07:32 -0700

Working Group Last Call for draft-ietf-fecframe-sdp-elements-05

PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have
no corrections to the document please send to the list your approval
of the document as is.

And let's do this quickly. Please send comments to the list by
end-of-day Friday, April 23.

Thanks!,
Greg

On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) <[email-masked]> wrote:
> This revision simply fixed the boilerplate. No other changes. Could we run the 2nd wglc on this draft?
>
> Thanks,
> -acbegen
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: Sunday, April 04, 2010 3:29 PM
> To: Ali C. Begen (abegen)
> Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-05
>
>
> A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been successfully submitted by Ali Begen and posted to the IETF repository.
>
> Filename:        draft-ietf-fecframe-sdp-elements
> Revision:        05
> Title:           SDP Elements for FEC Framework
> Creation_date:   2010-04-04
> WG ID:           fecframe
> Number_of_pages: 21
>
> Abstract:
> This document specifies the use of Session Description Protocol (SDP)
> to describe the parameters required to signal the Forward Error
> Correction (FEC) Framework Configuration Information between the
> sender(s) and receiver(s).  This document also provides examples that
> show the semantics for grouping multiple source and repair flows
> together for the applications that simultaneously use multiple
> instances of the FEC Framework.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 20 Apr 2010 10:43:20 -0700

Please folks!! We can't honestly progress this doc without feedback
from the group. Read and respond this week and we can work toward
completing this goals of this group and moving on.

Thanks!,
Greg

---

From: "Orly Peck" <[email-masked]>
Date: Thu, 22 Apr 2010 12:57:02 +0300

Hi, 
Here are my comments to draft-ietf-fecframe-sdp-elements-05:

1) section 4.6 - Repair Window - " Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process."

I think that the assumption that there is no issue of delay variation is irrelevant for most cases.
I think the Repair Window should be defined (as I mentioned at the last IETF meeting) as the MINIMUM time that the receiver should wait for the repair packets, as the sender only knows the time that spans between the source packets and the generation of the repair packets.
This comment was accepted also by Mark Watson for draft-ietf-fecframe-framework-05.

2) same section - typo: mismatchs = mismatches.

Thanks,
Orly Peck.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Wednesday, April 14, 2010 8:08 PM
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05

Thanks!,
Greg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Apr 2010 04:15:16 -0700

Thanks for the review. Good catch for both. Will make the changes after wglc closes.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Orly Peck
> Sent: Thursday, April 22, 2010 5:57 AM
> To: [email-masked]
> Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
> 
> Hi,
> 1) section 4.6 - Repair Window - " Assuming that there is no issue of delay variation, the FEC decoder
> SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery
> process."
> 
> I think the Repair Window should be defined (as I mentioned at the last IETF meeting) as the MINIMUM
> time that the receiver should wait for the repair packets, as the sender only knows the time that
> spans between the source packets and the generation of the repair packets.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Apr 2010 15:36:52 +0100

A nit: the examples in section 5.3 include white-space between the FEC  
attribute names and their parameters, but the ABNF doesn't seem to  
allow this.

Colin

On 14 Apr 2010, at 18:07, Greg Shepherd wrote:
> On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) <[email-masked] 
> > wrote:
>> A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has  
>> been successfully submitted by Ali Begen and posted to the IETF  
>> repository.
>>

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Apr 2010 08:53:47 -0700

Good catch. Thanks and it is fixed.
-acbegen

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 10:37 AM
> To: [email-masked]
> Cc: Ali C. Begen (abegen); [email-masked]

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Apr 2010 09:33:02 -0700

Is the WG happy with the text below?

-acbegen

An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver side, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets, if there are any. Repair window stands for the time that spans the source packets and the corresponding repair packets. It defines the minimum time which the receiver SHOULD wait for the repair packets.

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 22 Apr 2010 09:44:08 -0700

Repair window from the receiver perspective doesn't seem very well defined in this text.  Is it specified somewhere else in the spec what the repair window is from the receiver perspective, i.e., how does the receiver know when the repair window starts and how does the receiver know the duration of the repair window (is it signaled?).

On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Apr 2010 12:11:41 -0700

I suppose the receiver can only start counting when it received the first packet in a source block (it can make adjustments if there were missing packets at the beginning of the block).

And yes, this is specified in the SDP description. When it is signaled there, the sender conforms to it and the receiver knows about it.

-acbegen

> From: Luby, Michael [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 12:44 PM
> To: Ali C. Begen (abegen); Orly Peck; [email-masked]
> Repair window from the receiver perspective doesn’t seem very well defined in this text.  Is it
> specified somewhere else in the spec what the repair window is from the receiver perspective, i.e.,
> how does the receiver know when the repair window starts and how does the receiver know the duration
> of the repair window (is it signaled?).
> 
> 
> 	An FEC encoder processes a block of source packets and generates a number of repair packets,
> which are then transmitted within a certain duration. At the receiver side, the FEC decoder tries to
> decode all the packets received within the repair window to recover the missing packets, if there are
> any. Repair window stands for the time that spans the source packets and the corresponding repair
> packets. It defines the minimum time which the receiver SHOULD wait for the repair packets.
> 
> 	> > This revision simply fixed the boilerplate. No other changes. Could we run the 2nd wglc on
> this
> 	> draft?
> 	> >
> 	> > Thanks,
> 	> > -acbegen
> 	> >
> 	> > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been successfully
> submitted by Ali
> 	> Begen and posted to the IETF repository.
> 	> >

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 22 Apr 2010 12:13:30 -0700

Ok, it seems that if the receiver SHOULD do something then the text should explain how it should do that.

On 4/22/10 12:11 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

-acbegen

> Repair window from the receiver perspective doesn't seem very well defined in this text.  Is it

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 22 Apr 2010 12:57:24 -0700

OK, what about this (section 4.6):

Repair window is the time that spans an FEC block, which consists of the source block and the corresponding repair packets.
 
At the sender side, the FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration not larger than the value of the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in an FEC block to allow all the repair packets to arrive (The waiting time can be adjusted if there are mising packets at the beginning of the FEC block). The FEC decoder may start decoding the already received packets sooner, however, it SHOULD NOT register an FEC decoding failure until it waits at least for the repair-window duration.

-acbegen

> Sent: Thursday, April 22, 2010 3:14 PM

---

From: "Orly Peck" <[email-masked]>
Date: Sun, 25 Apr 2010 10:13:24 +0300

Two things that you may consider adding to the text:

1) The Repair-Window impacts the maximum number of source packets in a
FEC block.
2) I think it might be useful to add the option for the sender and
receiver to negotiate this value with SDP offer-answer.

Thanks,
Orly Peck.

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Thursday, April 22, 2010 10:57 PM
To: Luby, Michael; Orly Peck; [email-masked]
Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05

Repair window is the time that spans an FEC block, which consists of the
source block and the corresponding repair packets.
 
At the sender side, the FEC encoder processes a block of source packets
and generates a number of repair packets, which are then transmitted
within a certain duration not larger than the value of the repair
window. At the receiver side, the FEC decoder should wait at least for
the duration of the repair window after getting the first packet in an
FEC block to allow all the repair packets to arrive (The waiting time
can be adjusted if there are mising packets at the beginning of the FEC
block). The FEC decoder may start decoding the already received packets
sooner, however, it SHOULD NOT register an FEC decoding failure until it
waits at least for the repair-window duration.

-acbegen

> Ok, it seems that if the receiver SHOULD do something then the text
should explain how it should do
> that.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 26 Apr 2010 07:13:38 -0700

> 1) The Repair-Window impacts the maximum number of source packets in a

This was implied but I am fine with making it explicit. 

> receiver to negotiate this value with SDP offer-answer.

I believe the way it works is that the sender makes multiple offers with different RW values (or other parameters) and the client chooses the one it likes, or probably can make a counter proposal.

Do we need additional text for this?

-acbegen

---

From: "Orly Peck" <[email-masked]>
Date: Mon, 26 Apr 2010 20:11:47 +0300

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: Monday, April 26, 2010 5:14 PM
To: Orly Peck; Luby, Michael; [email-masked]
Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05

[Orly Peck] ok

> receiver to negotiate this value with SDP offer-answer.

I believe the way it works is that the sender makes multiple offers with
different RW values (or other parameters) and the client chooses the one
it likes, or probably can make a counter proposal.

Do we need additional text for this?
[Orly Peck] if this is obvious then I guess no additional text is
needed.

-acbegen

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Apr 2010 13:43:12 -0400

Hi Orly,

you didn't spot it so it must not have been obvious. Explicit is
usually better.

dbh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Orly Peck
> Sent: Monday, April 26, 2010 1:12 PM
> To: Ali C. Begen (abegen); [email-masked]
> > Repair window is the time that spans an FEC block, which consists
of
> the
> > can be adjusted if there are mising packets at the beginning of
the
> FEC
> > sooner, however, it SHOULD NOT register an FEC decoding 
> failure until
> it

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Apr 2010 13:47:35 -0400

Hi,

Just jumping into the middle without reading the whole document or
anything ;-)
<as an individual contributor>

> [mailto:[email-masked]] On Behalf Of Ali C. Begen
(abegen)
> Sent: Thursday, April 22, 2010 3:57 PM
> Repair window is the time that spans an FEC block, which 
> consists of the source block and the corresponding repair packets.

! And yes, this is specified in the SDP description. When it is
signaled there, the sender 
! conforms to it and the receiver knows about it.

If I understand correctly, would it be good to include in this
definition of repair window that it is specified in the SDP
description?