Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt

From: [email-masked]
Date: Wed, 25 Jul 2018 02:50:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Forward Error Correction (FEC) Framework Extension to Sliding Window Codes
        Authors         : Vincent Roca
                          Ali Begen
	Filename        : draft-ietf-tsvwg-fecframe-ext-03.txt
	Pages           : 20
	Date            : 2018-07-25

Abstract:
   RFC 6363 describes a framework for using Forward Error Correction
   (FEC) codes to provide protection against packet loss.  The framework
   supports applying FEC to arbitrary packet flows over unreliable
   transport and is primarily intended for real-time, or streaming,
   media.  However FECFRAME as per RFC 6363 is restricted to block FEC
   codes.  The present document extends FECFRAME to support FEC Codes
   based on a sliding encoding window, in addition to Block FEC Codes,
   in a backward compatible way.  During multicast/broadcast real-time
   content delivery, the use of sliding window codes significantly
   improves robustness in harsh environments, with less repair traffic
   and lower FEC-related added latency.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-fecframe-ext-03
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-fecframe-ext-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-fecframe-ext-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vincent Roca <[email-masked]>
Date: Wed, 25 Jul 2018 12:10:27 +0200

Hello Wes, all,

We have just updated the FECFRAME extension and RLC FEC Scheme for FECFRAME I-Ds as
discussed during IETF 102 meeting. Those updates fix a few typos, slightly improve text, add
an acknowledgment section. We authors do not think it requires a new WGLC.

Cheers,

   Vincent

NB: if one looks at the RLC FEC Scheme diff:
	https://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-06.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-06.txt>
	one may think that Appendix A providing the TinyMT32 C-code has been significantly changed.
	This is not the case, we merely updated a few comments (in particular added references
	for the initial PRNG state parameters’ choice). The rfcdiff tool seems to have lost tracks.

> Le 25 juil. 2018 à 11:50, [email-masked] a écrit :
> 
>

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 25 Jul 2018 10:06:31 -0400

> an acknowledgment section. We authors do not think it requires a new WGLC.

Thanks.  I think everyone who commented during the WGLC has now 
confirmed that they're happy with the changes, so I'll start the 
shepherd write-up.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 25 Jul 2018 10:34:40 -0400

> an acknowledgment section. We authors do not think it requires a new WGLC.

Hi Vincent, one part of the shepherd write-up asks us to make sure that 
if any other RFCs are updated, obsoleted, etc., that it's indicated 
properly.

As this document explains, it extends but doesn't replace RFC 6363.

One could see this as a definite case for having it say "Updates: 6363" 
in the header.  Do you agree, or was there a reason I've forgotten why 
we decided not to indicate that?

---

From: Vincent Roca <[email-masked]>
Date: Wed, 25 Jul 2018 17:00:04 +0200

> Le 25 juil. 2018 à 16:34, Wesley Eddy <[email-masked]> a écrit :
> 
> Hi Vincent, one part of the shepherd write-up asks us to make sure that if any other RFCs are updated, obsoleted, etc., that it's indicated properly.
> 
> One could see this as a definite case for having it say "Updates: 6363" in the header.  Do you agree, or was there a reason I've forgotten why we decided not to indicate that?

I think the question has never been asked like that.

My first idea, back in 2016, was to replace RFC 6363 altogether.
Then David had this key remark that in fact we just want to extend RFC 6363 and the title reflects this.

I don’t know what « updates RFC 6363 » implies exactly. If « updates » implies « replaces » then the
answer is no. RFC 6363 will remain as is, without any change, we just add a new capability to it.

The new FECFRAME standard should now be understood as the combination:
	RFC 6363 + RFC XXX (this doc).

Does it answer?
Cheers,

  Vincent

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 25 Jul 2018 11:10:57 -0400

> 	RFC 6363 + RFC XXX (this doc).

It sounds like "Updates" has the right semantics then.  What we don't 
want is "Obsoletes".

FYI, it's defined in 2223:

    Updates

       To be used as a reference from a new item that cannot be used
       alone (i.e., one that supplements a previous document), to refer
       to the previous document.  The newer publication is a part that
       will supplement or be added on to the existing document; e.g., an
       addendum, or separate, extra information that is to be added to
       the original document.

---

From: "Black, David" <[email-masked]>
Date: Wed, 25 Jul 2018 15:20:50 +0000

> answer is no. RFC 6363 will remain as is, without any change, we just add a

Here, "updates" means "extends or modifies."    Looking at the two drafts, there appear to be two different outcomes.

1) The fecframe-ext draft clearly extends the RFC 6363 framework.   In addition, Section 5.3 definitely modifies RFC 6363, as indicated by the first paragraph in that section:

   The FEC Scheme requirements of [RFC6363], Section 5.6, mostly apply
   to this FECFRAME extension and are not repeated here.  An exception
   though is the "full specification of the FEC code", item (4), that is
   specific to block FEC codes.  The following item (4) applies in case
   of Sliding Window FEC schemes:

So, it looks like the fecframe-ext draft need an "Updates: 6363" header, and the draft will need a section summarizing changes to RFC 6363 - at least the section 5.3 change, and also identifying any normative text in RFC 6363 that doesn't apply to Sliding Window Codes.

2) In contrast, the rlc-fec-scheme draft appears to use the RFC 6363 framework as extended by the fecframe-ext draft without modifying that framework.  If that is correct, it does not need an "Updates: 6363" header, as all the changes & extensions to RFC 6363 ought to be in the fecframe-ext draft.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Vincent Roca
> Sent: Wednesday, July 25, 2018 11:00 AM
> To: Wesley Eddy
> Cc: [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-fecframe-ext-03.txt
> 
> > Hi Vincent, one part of the shepherd write-up asks us to make sure that if
> any other RFCs are updated, obsoleted, etc., that it's indicated properly.
> >
> > One could see this as a definite case for having it say "Updates: 6363" in the
> header.  Do you agree, or was there a reason I've forgotten why we decided
> not to indicate that?
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 25 Jul 2018 14:58:56 -0500

I don't want to read ahead of the assignment, of course :D ...

On Wed, Jul 25, 2018 at 10:21 AM Black, David <[email-masked]> wrote:

> > answer is no. RFC 6363 will remain as is, without any change, we just
> add a
> > new capability to it.
>
> Here, "updates" means "extends or modifies."    Looking at the two drafts,
> there appear to be two different outcomes.
>
> 1) The fecframe-ext draft clearly extends the RFC 6363 framework.   In
> addition, Section 5.3 definitely modifies RFC 6363, as indicated by the
> first paragraph in that section:
>
> So, it looks like the fecframe-ext draft need an "Updates: 6363" header,
> and the draft will need a section summarizing changes to RFC 6363 - at
> least the section 5.3 change, and also identifying any normative text in
> RFC 6363 that doesn't apply to Sliding Window Codes.
>
> 2) In contrast, the rlc-fec-scheme draft appears to use the RFC 6363
> framework as extended by the fecframe-ext draft without modifying that
> framework.  If that is correct, it does not need an "Updates: 6363" header,
> as all the changes & extensions to RFC 6363 ought to be in the fecframe-ext
> draft.
>

I've served on six different IESGs, and I'm pretty sure I've never served
on one that didn't talk about what "Updates" REALLY means. But I think
David's conclusion is very defensible.

And if the Updates header is the only change that Wes identifies while
doing his Shepherd Write-up, I'm fine if you wait until after I do AD
Evaluation to submit a new version.

Thanks for talking this through.

Spencer

Thanks, --David
> > >> discussed during IETF 102 meeting. Those updates fix a few typos,
> slightly
> > improve text, add
> > Then David had this key remark that in fact we just want to extend RFC
> 6363
> > and the title reflects this.
> >
> > answer is no. RFC 6363 will remain as is, without any change, we just
> add a
> > new capability to it.
> >

---

From: Vincent Roca <[email-masked]>
Date: Thu, 26 Jul 2018 20:11:16 +0200

Hello Wes,

> Le 25 juil. 2018 à 17:10, Wesley Eddy <[email-masked]> a écrit :
> 
>>> Le 25 juil. 2018 à 16:34, Wesley Eddy <[email-masked]> <mailto:[email-masked]> a écrit :
> It sounds like "Updates" has the right semantics then.  What we don't want is "Obsoletes".
> 

That’s perfectly in line with the intent.
So we clearly update this RFC.

Thanks.

  Vincent

---

From: Vincent Roca <[email-masked]>
Date: Thu, 26 Jul 2018 20:11:25 +0200

Hello David,

> Le 25 juil. 2018 à 17:20, Black, David <[email-masked]> a écrit :
> 

I now fully agree.

> and the draft will need a section summarizing changes to RFC 6363 - at least the section 5.3 change, and also identifying any normative text in RFC 6363 that doesn't apply to Sliding Window Codes.

I realize the above text you quote is ambiguous. 

In fact Item (4) of RFC 6363 remains untouched but should be understood
as specific to block codes (it’s not indicated in RFC 6363 title of course).

In addition to that, this document adds what could be identified as 4-bis.

NEW:
   4-bis.  A full specification of the Sliding Window FEC code

I’ll clarify it in a future update.

> 2) In contrast, the rlc-fec-scheme draft appears to use the RFC 6363 framework as extended by the fecframe-ext draft without modifying that framework.  If that is correct, it does not need an "Upda…

Exactly, the RLC FEC Scheme does not update anything.

Thanks for the feedback and guidance.

   Vincent

---

From: Vincent Roca <[email-masked]>
Date: Thu, 26 Jul 2018 20:12:59 +0200

Hello Spencer,

> I've served on six different IESGs, and I'm pretty sure I've never served on one that didn't talk about what "Updates" REALLY means. But I think David's conclusion is very defensible.

Indeed. I fully agree with David/Wes.

> And if the Updates header is the only change that Wes identifies while doing his Shepherd Write-up, I'm fine if you wait until after I do AD Evaluation to submit a new version. 

No problem, I won’t submit any new version until you tell me to do so.

Thanks,

    Vincent