Subject: [tsvwg] AD Evaluation of draft-ietf-tsvwg-fecframe-ext-03 and draft-ietf-tsvwg-rlc-fec-scheme-06

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 2 Sep 2018 19:57:39 -0500

Dear FECsters,

My comments on both of these drafts follow. Please let me know if anything
I'm asking about is unclear, but otherwise, please do the right thing.

In general, I'm not seeing any show-stopper problems, but would like to
resolve these before I request Last Call on the drafts.

Thanks for doing this work.

Spencer, as responsible AD

--- Comments on draft-ietf-tsvwg-fecframe-ext-03

As we discussed on the mailing list - please add an "Updates: 6363" header
to the next revision you post.

This text confused me a bit:

  Many applications need to transport a continuous stream of packetized
   data from a source (sender) to one or more destinations (receivers)
   over networks that do not provide guaranteed packet delivery.  In
   particular packets may be lost, which is strictly the focus of this
   document: we assume that transmitted packets are either received
   without any corruption or totally lost (e.g., because of a congested
   router, of a poor signal-to-noise ratio in a wireless network, or
   because the number of bit errors exceeds the correction capabilities
   of a low-layer error correcting code).

"received without any corruption" doesn't seem to mesh with "the correction
capabilities of a low-layer error correcting code" - the way I was reading
this, "received without any corruption" would mean that there were no
errors for a low-layer error correcting code to correct. So, obviously, I'm
lost here. Could you help me find my way out?

In this text,

 However [RFC6363] only considers block FEC schemes defined in
   accordance with the FEC Building Block [RFC5052] (e.g., [RFC6681],
   [RFC6816] or [RFC6865]).  These codes require the input flow(s) to be
   segmented into a sequence of blocks.  Then FEC encoding (at a sender
   or an encoding middlebox) and decoding (at a receiver or a decoding
   middlebox) are both performed on a per-block basis.  This approach
   has major impacts on FEC encoding and decoding delays.  The data
   packets of continuous media flow(s) may be passed to the transport
   layer immediately, without delay.  But the block creation time, that
   depends on the number k of source symbols in this block, impacts the
   FEC encoding delay since encoding requires that all source symbols be
   known.  This block creation time also impacts the decoding delay a
   receiver will experience in case of erasures, since no repair symbol
   for the current block can be received before.

I don't see a context for "can be received before" - before what?

I understand that block FEC codes are still supported in a
backward-compatible way, but wonder if there are any situations where an
implementation that supports both block and sliding window FEC codes would
choose to use block FEC codes with another implementation that supports
both types of FEC codes? It seems like this document would be a good place
to explain how you choose between block and sliding window FEC code types.

Nit: I saw a "Section Section 3" that should be "Section 3".

I recognize that this text is unchanged, but

   Transport Protocol:  The protocol used for the transport of the
       source and repair flows, e.g., UDP and the Datagram Congestion
       Control Protocol (DCCP).

is now ambiguous, because DCCP-UDP was defined after RFC 6363 was published
- it's in https://tools.ietf.org/html/rfc6773. Is that relevant for this
document?

In this text,

3.  Architecture Overview

   The architecture of [RFC6363], Section 3, equally applies to this
   FECFRAME extension and is not repeated here.  However we provide
   hereafter a quick summary to facilitate the understanding of this
   document to readers not familiar with the concepts and terminology.

I see that [RFC6363], Section 3 is also called "Architecture Overview". It
might be less confusing to the reader if this summary had a different
section title (perhaps "Summary of Architecture Overview").

I'm thinking after seeing this text

  FEC Source Packets (containing ADUs) and FEC Repair Packets
   (containing one or more repair symbols each) are then generated and
   sent using UDP (more precisely [RFC6363], Section 7, requires a
   transport protocol providing an unreliable datagram service, like UDP
   or DCCP).

that you might want to resolve my question about DCCP-UDP earlier, and then
think about whether you want to call out specific datagram protocols at
various points in the document, or just say "transport protocol" after
you're sure that the definition of "transport protocol" says what you want
it to say.

I'm confused about the relationship between

  o  MUST define the management of the encoding window that slides over
      the set of ADUs.  Appendix A provides a non normative example;

which thinks Appendix A is an example, and

Appendix A.  About Sliding Encoding Window Management (non Normative)

   The FEC Framework does not specify the management of the sliding
   encoding window which is the responsibility of the FEC Scheme.  This
   annex only provides a few non normative hints.

which thinks Appendix A is giving hints. I'd suggest using the same wording
in both places.

If Appendix A is giving hints, perhaps the reference to Appendix A could be
something like

  o  MUST define the management of the encoding window that slides over
      the set of ADUs.  Appendix A provides non normative hints about what
      sliding window management implementers need to consider;

But do the right thing, of course.

I'm guessing at something, so could be completely wrong, but I'm seeing

10.  Security Considerations

   This FECFRAME extension does not add any new security consideration.
   All the considerations of [RFC6363], Section 9, apply to this
   document as well.

in this document (which could be true), and I'm seeing

9.1.  Problem Statement

   A content delivery system is potentially subject to many attacks.
   Attacks can target the content, the CDP, or the network itself, with
   completely different consequences, particularly in terms of the
   number of impacted nodes.

   Attacks can have several goals:

<snip>

   o  They can try to compromise the receiver's behavior (e.g., by
      making the decoding of an object computationally expensive), which
      is another form of DoS attack.

in [RFC6363], and I'm wondering whether there are more opportunities for
make decoding an object computationally expensive when sliding window
coding is used. If that's not true, please step over my comment and
continue :-)

--- Comments on draft-ietf-tsvwg-rlc-fec-scheme-06

Please have someone who doesn't understand FEC as well as the authors do,
take a look at the Abstract and Introduction, to make sure it's accessible
for likely readers and implementers. I started hunting when I saw "GF" used
in the Abstract and Introduction with no expansion, which isn't given until
the 11th occurrence of the string "GF" in the draft (so, now I know you
meant "Galois Field"). I don't think this will be difficult, but remember
that (among other things) we still publish Abstracts separately from the
rest of the document, so they need to make sense on their own.

I suspect it's worth mentioning that this work is exploiting the
availability of fecframe-ext in the Abstract, as well. Otherwise, the
reader doesn't know about that dependency until the middle of page 4.

Nit: s/focusses/focuses/

In this text,

  Code rate, cr:  The code rate parameter determines the amount of
      redundancy added to the flow.  More precisely the cr is the ratio
      between the total number of source symbols and the total number of
      source plus repair symbols and by definition: 0 < cr <= 1.  This
      is an input parameter that enables a FECFRAME sender to derive
      other internal parameters, as explained below.  However there is
      no need to communicate the cr parameter per see (it's not required
      to process a repair symbol at a receiver).  This code rate
      parameter can be fixed.  However, in specific use-cases (e.g.,
      with unicast transmissions in presence of a feedback mechanism
      that estimates the communication quality, out of scope of
      FECFRAME), the code rate may be adjusted dynamically.

"this code rate parameter can be fixed" is correct, but perhaps "this code
rate parameter can be static" would be less likely to confuse readers.

If

   The features of the
   flow (in particular its minimum/maximum bitrate) may be known or not.

doesn't cover anything except the minimum and maximum bitrates,

   The flow's minimum/maximum bitrate might or might not be known.

might be clearer to the reader.

This text

8.  Security Considerations

   The FEC Framework document [RFC6363] provides a comprehensive
   analysis of security considerations applicable to FEC Schemes.

might be correct, or not, depending on the answer to my question about the
Security Considerations section in draft-ietf-tsvwg-fecframe-ext.
Some of the references to [RFC6363] include specific section numbers, but
others do not. Could you take a look at this, and see if there are cases
where including a section number would be useful for the reader?

The second of these considerations does a good job of explaining exactly
what will happen if an attack is successful, but the first just says the
attacker can enable a DOS attack.

  o  FEC Encoding ID: changing this parameter leads the receivers to
      consider a different FEC Scheme, which enables an attacker to
      create a Denial of Service (DoS);
   o  Encoding symbol length (E): setting this E parameter to a
      different value will confuse the receivers and create a DoS.  More
      precisely, the FEC Repair Packets received will probably no longer
      be multiple of E, leading receivers to reject them;

Is it possible for describe the effect of the first attack, in more detail
than "DOS"? Would this prevent FEC from succeeding, for instance?

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 5 Sep 2018 14:02:34 +0300

Hi Spencer

> On Sep 3, 2018, at 3:57 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear FECsters, 
> 
> My comments on both of these drafts follow. Please let me know if anything I'm asking about is unclear, but otherwise, please do the right thing. 
> 
> In general, I'm not seeing any show-stopper problems, but would like to resolve these before I request Last Call on the drafts.
> 
> As we discussed on the mailing list - please add an "Updates: 6363" header to the next revision you post.
> 
> "received without any corruption" doesn't seem to mesh with "the correction capabilities of a low-layer error correcting code" - the way I was reading this, "received without any corruption" would mean that there were no errors for a low-layer error correcting code to correct. So, obviously, I'm lost here. Could you help me find my way out?

What about we say “either received fully” or “either received without any error”?

The data may have arrived with errors but the lower-layer FEC might have fixed them so that to the IP/transport layer, the data looks intact.

> I don't see a context for "can be received before" - before what?

s/before/prior to receiving the source packets

> 
> I understand that block FEC codes are still supported in a backward-compatible way, but wonder if there are any situations where an implementation that supports both block and sliding window FEC codes would choose to use block FEC codes with another implementation that supports both types of FEC codes? It seems like this document would be a good place to explain how you choose between block and sliding window FEC code types.

Is not this part of the initial configuration or negotiation between the end points? I mean if the source sticks with block based fec, the client has to use that.

> 
> Nit: I saw a "Section Section 3" that should be "Section 3”. 

OK.

> is now ambiguous, because DCCP-UDP was defined after RFC 6363 was published - it's in https://tools.ietf.org/html/rfc6773. Is that relevant for this document? 

Can we simply delete DCCP? No disrespect but I have not seen a single implementation running DCCP. Saying UDP covers all the possible protocols.

> I see that [RFC6363], Section 3 is also called "Architecture Overview". It might be less confusing to the reader if this summary had a different section title (perhaps "Summary of Architecture Overview”).

OK.

> that you might want to resolve my question about DCCP-UDP earlier, and then think about whether you want to call out specific datagram protocols at various points in the document, or just say "transport protocol" after you're sure that the definition of "transport protocol" says what you want it to say.

I am inclined not to use specific names and simply use “transport protocol”.

> which thinks Appendix A is giving hints. I'd suggest using the same wording in both places. 
> 
> If Appendix A is giving hints, perhaps the reference to Appendix A could be something like 
> 

This works for me.

> in [RFC6363], and I'm wondering whether there are more opportunities for make decoding an object computationally expensive when sliding window coding is used. If that's not true, please step over my comment and continue :-)

I will let Vincent answer this as he probably knows more than I do about this. That could be possible but for that, I’d expect the individual FEC scheme to go into the details about the protection against such problems. To be on the safe side, we might want to add a generic statement here.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 5 Sep 2018 10:45:31 -0500

Hi, Ali,

Thanks for these. Just to follow up where we still have things to talk
about ...

On Wed, Sep 5, 2018 at 6:02 AM Ali C. Begen <[email-masked]>
wrote:

> > My comments on both of these drafts follow. Please let me know if
> anything I'm asking about is unclear, but otherwise, please do the right
> thing.
> >
> > "received without any corruption" doesn't seem to mesh with "the
> correction capabilities of a low-layer error correcting code" - the way I
> was reading this, "received without any corruption" would mean that there
> were no errors for a low-layer error correcting code to correct. So,
> obviously, I'm lost here. Could you help me find my way out?
>
> The data may have arrived with errors but the lower-layer FEC might have
> fixed them so that to the IP/transport layer, the data looks intact.
>

Yeah, that's what I wasn't seeing clearly in the existing text. Do the
right thing, of course.

> Is not this part of the initial configuration or negotiation between the
> end points? I mean if the source sticks with block based fec, the client
> has to use that.
>

Understood, but my question was whether there is general advice you could
give ("if both are available, favor sliding window FEC", or "if both are
available, favor sliding window FEC unless you're in this particular use
case" types of things).

As you mention below (when I asked about new security exposures for DoS),
it might be more reasonable to ask about this for specific sliding window
FEC methods, so don't think you have to answer my dumb question if
answering a smarter question that I should have asked leads to a better
result ;-) ...

> > is now ambiguous, because DCCP-UDP was defined after RFC 6363 was
> published - it's in https://tools.ietf.org/html/rfc6773. Is that relevant
> for this document?
>
> Can we simply delete DCCP? No disrespect but I have not seen a single
> implementation running DCCP. Saying UDP covers all the possible protocols.
>

I couldn't possibly comment on this one, because ADs don't make decisions
like that for WG documents, but fortunately, I cc: the working group on AD
Evaluations, so people who could comment, probably ought to comment now ...

> > I see that [RFC6363], Section 3 is also called "Architecture Overview".
> It might be less confusing to the reader if this summary had a different
> section title (perhaps "Summary of Architecture Overview”).
>
> OK.
>
> >
> > that you might want to resolve my question about DCCP-UDP earlier, and
> then think about whether you want to call out specific datagram protocols
> at various points in the document, or just say "transport protocol" after

The more I think about this, the more I'm thinking that the document has a
perfectly lovely definition for "transport protocol", modulo whatever
happens to DCCP, and using that term instead of using specific names
throughout the document would be helpful if this work is somehow sucked
into QUIC partial reliability with FEC, or whatever we do with
next-generation datagram protocols ... so I think you're probably inclined
in a helpful direction.

> I will let Vincent answer this as he probably knows more than I do about
> this. That could be possible but for that, I’d expect the individual FEC
> scheme to go into the details about the protection against such problems.
> To be on the safe side, we might want to add a generic statement here.
>

I asked the question, so will let smarter people do the right thing here.

And thanks for the quick response.

Spencer

---

From: Vincent Roca <[email-masked]>
Date: Fri, 7 Sep 2018 15:53:20 +0200

Dear Spencer,

> Spencer, as responsible AD

You’re welcome.

You’ll find below Ali and myself answers to your comments (first part of the email, FECFRAME extended)
followed by Belkacem and myself answers (2nd part, RLC). The two updated I-Ds have been submitted too.
It also considers comments received end of July (« updates » and ambiguity, just below).

Cheers,

  Ali, Belkacem, Vincent

====================================================

> --- Comments on draft-ietf-tsvwg-fecframe-ext-03

[Authors] Spencer, in order to reflect discussions end of July on the list, we have added the updates attribute in the header:

NEW:
Updates: 6363 (if approved)

[Authors] During end of July discussion on the list, we also identified a misleading sentence in Section 5.3. I said:

> [David B.] 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:
   An exception
   though is the "full specification of the FEC code", item (4), that is
   specific to block FEC codes.  The following item (4-bis) applies in
   case of Sliding Window FEC schemes:

   4-bis.  A full specification of the Sliding Window FEC code
	[…]

> "received without any corruption" doesn't seem to mesh with "the correction capabilities of a low-layer error correcting code" - the way I was reading this, "received without any corruption" would…

[Authors] You’re perfectly right, this is confusing. We had in mind the layered model,
so when a datagram arrives at the transport layer, potential bit errors, if any, have
been fixed at the PHY layer and therefore hidden. 

NEW:
[…]
   In particular packets may be lost, which is strictly the focus of this
   document: we assume that transmitted packets are either lost (e.g.,
   because of a congested router, of a poor signal-to-noise ratio in a
   wireless network, or because the number of bit errors exceeds the
   correction capabilities of the physical-layer error correcting code) or
   received by the transport protocol without any corruption (i.e., the
   bit-errors, if any, have been fixed by the physical-layer error
   correcting code and therefore are hidden to the upper layers).

NB: the order is changed, we first explain potential causes for lost packets,
then continue with those « perfectly » received. It’s more natural IOHO.

We have changed accordingly the definition of "Packet Erasure Channel »
in Section 2, using a more compact explanation:

OLD:
Packet Erasure Channel: A communication path where packets are either
      lost (e.g., by a congested router, or because the number of
      transmission errors exceeds the correction capabilities of the
      physical-layer codes) or received. When a packet is received, it is
      assumed that this packet is not corrupted.

NEW:
   Packet Erasure Channel:  A communication path where packets are
       either lost (e.g., in our case, by a congested router, or because
       the number of transmission errors exceeds the correction
       capabilities of the physical-layer code) or received.  When a
       packet is received, it is assumed that this packet is not
       corrupted (i.e., in our case, the bit-errors, if any, are fixed
       by the physical-layer code and therefore hidden to the upper
       layers).

> I don't see a context for "can be received before" - before what?

[Authors] … before the block creation time. We tried to clarify as follows:

NEW:
   […] But the block creation time, that
   depends on the number of source symbols in this block, impacts both
   the FEC encoding delay (since encoding requires that all source
   symbols be known), and mechanically the packet loss recovery delay at
   a receiver (since no repair symbol for the current block can be
   generated and therefore received before that time).

NB: « before that time » is more safe than « prior to to receiving the source packets »
	as we may imagine that an (stupid?) implementer does not transmit source
	packets on the fly but waits during that delay, then sends all repair packets
	followed by the source packets. There’s no gain IMHO in doing that, but it
	would contradict the « prior to receiving the source packets ». We’re safe if
	we mention the block creation time.

NB: I’ve removed the « k » in "the number k of source symbols in this block ».
	It’s useless in this context.

> I understand that block FEC codes are still supported in a backward-compatible way, but wonder if there are any situations where an implementation that supports both block and sliding window FEC co…

[Authors] Yes, backward compatibility is guaranteed.
Otherwise Gorry, during the RLC I-D WGLC, made a somewhat opposed comment (email sent on May 1st)
and we answered as follows (email sent on May 4th):
— 
> ---

> /are extremely efficient/

> - This seems like a value judgment. I'd be content with saying /efficient/, but to say more I feel really needs a strong evidence that has consensus. RFCs must not be used to market techniques.

VR: Sure, you’re right. I propose the following sentence: 

OLD:
	These FEC Schemes are extremely efficient for instance with media that
	feature real-time constraints sent within a multicast/broadcast session.

NEW:
	These FEC Schemes, and more generally sliding window FEC codes, are recommended
	for instance with media that feature real-time constraints sent within a multicast/broadcast
	session [Roca17].
— 
Isn’t it a good balance between recommendations and advertisement/marketing? It refers to an
external published article where details can be found, but that is specific to a well defined use-case
that I don't want to (and can't) generalize.

NB: the above NEW text is (already) in the associated RLC I-D, but not in this FECFRAME extension I-D
       which is more generic.

You also said in an answer to Ali:

> Understood, but my question was whether there is general advice you could give ("if both are available, favor sliding window FEC", or "if both are available, favor sliding window FEC unless you're in this particular use case" types of things). 

[Authors] When we say (Abstract):
   "the use of sliding window codes significantly improves robustness in harsh environments,
    with less repair traffic and lower FEC-related added latency » 
(and we have similar claims in Introduction) it’s already a strong incentive to switch to these codes.

> Nit: I saw a "Section Section 3" that should be "Section 3". 

[Authors] Fixed. I sometimes forget that <xref target=« … »/> adds the « Section » keyword

> is now ambiguous, because DCCP-UDP was defined after RFC 6363 was published - it's in https://tools.ietf.org/html/rfc6773 <https://tools.ietf.org/html/rfc6773>. Is that relevant for this document? 

[Authors] As Ali suggested: "can we simply delete DCCP? No disrespect but I have not seen a single implementation running DCCP."
  DCCP (DCCP-UDP or STD) remains an option, as said in RFC6363 (no change). From your answer, we understand 
  Additionally we clarify in the above Transport Protocol definition that we consider an unreliable datagram service (it was missing).

NEW:
   Transport Protocol:  The protocol used for the transport of the
       source and repair flows, using an unreliable datagram service
       such as UDP.

There are a few places (introduction and section 3) that are updated too to only refer UDP.

> I see that [RFC6363], Section 3 is also called "Architecture Overview". It might be less confusing to the reader if this summary had a different section title (perhaps "Summary of Architecture Overview »).

[Authors] Agreed.

> that you might want to resolve my question about DCCP-UDP earlier, and then think about whether you want to call out specific datagram protocols at various points in the document, or just say "tran…

[Authors] Yes, that’s a good idea. The various figures of RFC6363 mention « Transport Layer (e.g., UDP) »
but we can simplify with « Transport Protocol » since it is now well defined.
As a side effect, we updated mentions to "UDP repair flows » at the start of  4.2 and 4.3.

OLD:
   With a Sliding Window FEC Scheme, the following operations,
   illustrated in Figure 2 for the case of UDP repair flows, and in
   Figure 3 for the case of RTP repair flows, […]

NEW:
   With a Sliding Window FEC Scheme, the following operations,
   illustrated in Figure 2 for the generic case (non-RTP repair flows),
   and in Figure 3 for the case of RTP repair flows, […]

Indeed, the RTP repair flow is a very particular case, and therefore the opposite
can be qualified as the generic case.

> But do the right thing, of course. 

[Authors] You’re perfectly right, Appendix A gives hints, not an example.
There are two references to Appendix A (4.2 and 5.3), the wording is now the same:

NEW:
     Appendix A provides non normative hints about
      what FEC Scheme designers need to consider;

> in [RFC6363], and I'm wondering whether there are more opportunities for make decoding an object computationally expensive when sliding window coding is used. If that's not true, please step over m…

[Authors] I’m the one who wrote RFC6363 Security Considerations. Honestly, the situation
is pretty much the same, especially if we remain at the FECFRAME framework (this document).

If we focus to a specific Sliding Window FEC Scheme, there can be more
specific aspects to consider. This is exactly what we do in the RLC FEC Scheme I-D.

That being said, we can be more explicit in draft-ietf-tsvwg-rlc-fec-scheme-06 with potential consequences
(see below)...

========================================

> Please have someone who doesn't understand FEC as well as the authors do, take a look at the Abstract and Introduction, to make sure it's accessible for likely readers and implementers. I started hunting when I saw "GF" used in the Abstract and Introduction with no expansion, which isn't given until the 11th occurrence of the string "GF" in the draft (so, now I know you meant "Galois Field"). I don't think this will be difficult, but remember that (among other things) we still publish Abstracts separately from the rest of the document, so they need to make sense on their own. 

[Authors] Of course, and this is a mistake. Fixed. We also mention the equivalent « Finite Field » term
(even if we prefer the GF name in memory of this great French mathematician).

I’ll have this intro be read by a non specialist.

> I suspect it's worth mentioning that this work is exploiting the availability of fecframe-ext in the Abstract, as well. Otherwise, the reader doesn't know about that dependency until the middle of page 4. 

[Authors] Fixed. The reference to the other document is now explicit:

NEW:
   [...] They can
   protect arbitrary media streams along the lines defined by FECFRAME
   extended to sliding window FEC codes, as defined in [fecframe-ext].

> Nit: s/focusses/focuses/

[Authors] Fixed.

> "this code rate parameter can be fixed" is correct, but perhaps "this code rate parameter can be static" would be less likely to confuse readers. 

[Authors] Fixed. 
Question: in section 2, the E, br_in and br_out definitions all mention « assumed fixed (in xxx) ».
Up to you, is that clear enough or should we change it as well?

> :e#doesn't cover anything except the minimum and maximum bitrates, 
> 

[Authors] Fixed.

> might be correct, or not, depending on the answer to my question about the Security Considerations section in draft-ietf-tsvwg-fecframe-ext.
> Some of the references to [RFC6363] include specific section numbers, but others do not. Could you take a look at this, and see if there are cases where including a section number would be useful for the reader?
> 
> The second of these considerations does a good job of explaining exactly what will happen if an attack is successful, but the first just says the attacker can enable a DOS attack. 
> 
> Is it possible for describe the effect of the first attack, in more detail than "DOS"? Would this prevent FEC from succeeding, for instance? 

[Authors] Yes, and we added a lot of details in the new I-D version on potential
malfunctions triggered by corrupted parameters. The text is a bit long, it’s not
included here.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 7 Sep 2018 09:17:29 -0500

Dear Wes The Document Shepherd,

All this looks fine to me. Ready for Last Call on both docs?

Spencer

On Fri, Sep 7, 2018 at 8:53 AM Vincent Roca <[email-masked]> wrote:

> [Authors] Spencer, in order to reflect discussions end of July on the
> list, we have added the updates attribute in the header:
>
> NEW:
> [Authors] During end of July discussion on the list, we also identified a
> misleading sentence in Section 5.3. I said:
>
> [David B.] 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.
>
>
>    correction capabilities of the *physical*-layer error correcting code)
> *or*
> *   received by the transport protocol without any corruption (i.e., the*
> *   bit-errors, if any, have been fixed by the physical-layer error*
> *   correcting code and therefore are hidden to the upper layers).*
>
>        either lost (e.g., *in our case,* by a congested router, or because
>        corrupted* (i.e., in our case, the bit-errors, if any, are fixed*
> *       by the physical-layer code and therefore hidden to the upper*
> *       layers).*
>
>
> In this text,
>
>    symbols be known), *and mechanically the packet loss recovery delay at*
> *   a receiver (since no repair symbol for the current block can be*
> *   generated and therefore received before that time)*.
>
> - This seems like a value judgment. I'd be content with saying
> /efficient/, but to say more I feel really needs a strong evidence that has
> consensus. RFCs must not be used to market techniques.
>
>
> > Understood, but my question was whether there is general advice you
> could give ("if both are available, favor sliding window FEC", or "if both
> are available, favor sliding window FEC unless you're in this particular
> use case" types of things).
>
> [Authors] As Ali suggested: "can we simply delete DCCP? No disrespect but
> I have not seen a single implementation running DCCP."
>   Additionally we clarify in the above Transport Protocol definition that
> we consider an unreliable datagram service (it was missing).
>
> NEW:
>        source and repair flows, *using an unreliable datagram service*
> *       such as UDP.*
>
> section title (perhaps "Summary of Architecture Overview »).
>
>
> [Authors] Agreed.
>
>
>    illustrated in Figure 2 f*or the generic case (non-RTP repair flows)*,
> That being said, we can be more explicit in
> draft-ietf-tsvwg-rlc-fec-scheme-06 with potential consequences
> (see below)...
>
>
>    extended to sliding window FEC codes, *as defined in [fecframe-ext].*
>
>
> Nit: s/focusses/focuses/
>
>
> [Authors] Fixed.
>
> In this text,
>

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 7 Sep 2018 19:51:35 -0400

> All this looks fine to me. Ready for Last Call on both docs?

Yes; both sets of diffs good to me.