Subject: [nwcrg] TR: New Version Notification for draft-irtf-nwcrg-coding-and-congestion-01.txt

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 7 Feb 2020 07:52:02 +0000

Hello everyone, 

Following the fruitfull discussions we had at last IETF, we have been working on an updated version of the document. 
We have clarified the interactions between the transport congestion control and the FEC mechanism and clarified the scope of the document. 

We expect to further work on the document before the cut-off (and at least include a discussion on the receiver). 
In the meantime, please let us know if you have any views on this document.

Thanks, 

Nico

-----Message d'origine-----
De : [email-masked] <[email-masked]> 
Envoyé : vendredi 7 février 2020 08:12
À : Michael Welzl <[email-masked]>; Francois Michel <[email-masked]>; Kuhn Nicolas <[email-masked]>; Emmanuel Lochin <[email-masked]>
Objet : New Version Notification for draft-irtf-nwcrg-coding-and-congestion-01.txt

A new version of I-D, draft-irtf-nwcrg-coding-and-congestion-01.txt
has been successfully submitted by Nicolas Kuhn and posted to the IETF repository.

Name:		draft-irtf-nwcrg-coding-and-congestion
Revision:	01
Title:		Coding and congestion control in transport
Document date:	2020-02-06
Group:		nwcrg
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-coding-and-congestion-01.txt
Status:         https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/
Htmlized:       https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion
Diff:           https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-01

Abstract:
   Coding is a reliability mechanism that is distinct and separated from
   the loss detection of congestion controls.  Using coding can be a
   useful way to better deal with tail losses or with networks with non-
   congestion losses.  However, coding mechanisms should not hide
   congestion signals.  This memo offers a discussion of how coding and
   congestion control can coexist.  This document can help the
   comparison of FEC schemes by identifying at which level they are
   operating with respect to the transport congestion control.

   This document is the product of the Coding for Efficient Network
   Communications Research Group (NWCRG).  The scope of the document is
   end-to-end communications: coding for tunnels is out-of-the scope of
   the document.

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.

The IETF Secretariat

---

From: [email-masked]
Date: Sat, 8 Feb 2020 00:24:25 +0000 (UTC)

What is a "tail loss"? The trem is used repeatedly...

thanks

Lloyd [email-masked]

On Friday, February 7, 2020, 6:52 pm, Kuhn Nicolas <[email-masked]> wrote:

Hello everyone, 

Thanks, 

Nico

-----Message d'origine-----

Abstract:

The IETF Secretariat

_______________________________________________
nwcrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/nwcrg

---

From: Michael Welzl <[email-masked]>
Date: Sat, 8 Feb 2020 14:53:26 +0100

Thanks!  We’ll explain in the next version.
“Tail loss” has become a common term in transport - because it’s a common problem: e.g. web transfers are usually short, and it’s not uncommon to lose just the last few packets of them (hence “tail”) - but then, for these packets, the sender never gets a DupACK, and all that helps is a timeout, creating significant delay.

Cheers,
Michael

> On Feb 8, 2020, at 1:24 AM, lloyd.wood=[email-masked] wrote:
> 
> De : [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> 
> À : Michael Welzl <[email-masked] <mailto:[email-masked]>>; Francois Michel <[email-masked] <mailto:[email-masked]>>; Kuhn Nicolas <[email-masked] <mailto:[email-masked]>>; Emmanuel Lochin <[email-masked] <mailto:[email-masked]>>
> URL:            https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-coding-and-congestion-01.txt <https://www.ietf.org/internet-drafts/draft-irtf-nwcrg-coding-and-congestion-01.txt>
> Status:        https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/ <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/>
> Htmlized:      https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-01 <https://tools.ietf.org/html/draft-irtf-nwcrg-coding-and-congestion-01>
> Htmlized:      https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion <https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion>
> Diff:          https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-01 <https://www.ietf.org/rfcdiff?url2=draft-irtf-nwcrg-coding-and-congestion-01>
> 
> Abstract:
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/nwcrg <https://www.irtf.org/mailman/listinfo/nwcrg>

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 8 Feb 2020 21:24:23 +0000 (UTC)

Thanks, Michael.

that makes more sense -- the term, to me, invoked a router 
bug overwriting the tail of a packet in memory, but the 
packet is still delivered (because header checksums 
are a fixup, and a whole recomputation across the packet 
is not done) - in other words, the transport area 
that UDP Lite works in for end-corrupted (tail loss) 
packets, and was developed to address. 

Packet tail rather than session tail. 
And that really didn't fit with the context...

'session tail loss' or 'transfer tail loss' 
may be clearer.

Lloyd Wood [email-masked] http://about.me/lloydwood

On Sunday, 9 February 2020, 00:53:49 GMT+11, Michael Welzl <[email-masked]> wrote: 

Cheers,
Michael

---

From: Vincent Roca <[email-masked]>
Date: Tue, 18 Feb 2020 17:07:42 +0100

Dear authors, all,

A few comments on your document, version 01.
Sorry, it’s a bit long…

Cheers,    Vincent

—————— 

Abstract:
--------

- I do not understand:
   This document can help the
   comparison of FEC schemes by identifying at which level they are
   operating with respect to the transport congestion control.
What does "the comparison of FEC schemes" refer to? Between one another?
I guess this is not the intent (and this is explained later on).

- Global comment, title including: using "coding" without any further
information, is ambiguous. I'd prefer FEC coding or erasure correction coding,
at least in the abstract/introduction.

Introduction:
------

- Minor comment: It is said (2nd sentence):
   ... for the server to detect tail losses...
Make it clear that in this document, the server sends data.

- Ambiguous:
   One objective is to help the research community
   consider congestion control aspects when proposing and comparing
   coding solutions.
I'd rather say:
  Another objective is to encourage the research community to also consider congestion
  control aspects when proposing and comparing FEC coding solutions in communication
  systems.
Rationals: this is **another** objective; comparing FEC Schemes without considering
congestion control makes sense if **the goal is to compare those schemes only**.

Section 2:
----------

- A detail: arrows are missing in fig. 1.
Or perhaps it is indicated by the use of { and }, but in that case
it's not very clear. Using plural is also preferable.

- A detail: there is no "coded data" but "coded packets".

- It is said:
   "signaling from the receiver about losses and/or repaired blocks"
The use of "blocks" here is erroneous, we talk about packets.

- I'd also suggest that you change the mention "information about repaired ratio"
in fig. 2 by what you say here, in the text.
What exact information is given back to the FEC entity really depends on
the use-case, but I like the way it's written in the text: it's some information
about what is lost and what is recovered thanks to FEC coding.

- It is said:
   However, there can be meaningful other interactions
   (indicated by the horizontal double arrow) between the two entities,
There is no horizontal double arrow!
And I cannot really decide whether entities refer to client/server or CC/FEC.

typo:
- potiential => potential

Section 3:
----------

- Section 3.1 is pretty concise. What type of "transmission"? In intro you
say that tunnels are out of scope, which should be clarified and justified here.
Do you restrict yourself to transport protocols (where CC is usually found)?
Do you want to extend to application protocols as well (with the difficulty of
defining what is an application protocol, since we see more and more protocols
on top of UDP).
Do you consider multipaths?
Do you keep multicast as out of scope as there is a dedicated CC that is pretty
different?

- A new idea is introduced here, that of "fairness with non-coding solutions".
It should prominently mentioned in abstract and introduction as well.

- I'm surprised to see "Section 3.3.  Objective of the document" at this
moment in the document. Please put it before.
The first two sentences about mixing the CC and FEC channels should also be
moved at the end of section 2, it does not belong to the objectives.

Section 4:
----------

- I appreciate to see these three sections, but I think they should be grouped
as subsections of a single one entitled:
        "Recommendations depending on the CC versus FEC layering"
or something like that. And adding a small introduction text would be fine too.

- There's really an ambiguity about what is coded data: does it include
source data packets or not? And why data rather than packets?
Have a look at our terminology RFC and stick with it.

- I do not agree about the following wording:
   The drawback of this approach is that it is useless if the transport
   guarantees data delivery by retransmitting packets.
This is only a drawback if one is stupid enough to do FEC protection on top of
a reliable transport protocol. I'd rather say:
   Of course, this approach requires that that the transport protocol does not
   include a reliability (e.g., based on lost packet retransmition).
This approach is perfectly fine with UDP which is pretty usual.

- This is suggested in the figure ("sending rate or window"), but not detailed
in text. There is preferably a feedback between CC and FEC entities.

Section 4, 5, 6 globally:
-------------------------

- I see a major scoping problem in these sections.
What does this document really aim at? It is said earlier:
   This document discusses how FEC and CC relate.
Here we see architectural discussions on advantages/drawbacks instead.
There is also the additional idea of how it relates to transport reliability
mechanism which is (in theory) out of scope.

- I'd like to see more info about what concretely can be done (examples).
The case of QUIC and what was already proposed here to let FEC and CC work
together is pretty interesting.

- I also think the application (as data source) is potentially involved
in the big picture: an application generating a real-time data flow
is not the same as an application generating background traffic.
In the first case we could end up with situations where it's just impossible
to carry traffic by adding a certain redundancy, given the network conditions.
It means that without adapting the data flow there is probably no solution.
In the second case (which includes François's experiments with tail losses)
it's feasible.

Section 9:
----------

- Never say what follows:
   There is no security considerations required for this document.
There are security considerations in most documents, because it does change something
(which is fortunate) and therefore it can introduce threats.
Here CC and FEC coding rate could be leveraged to create DoS. Although it's not
specific to this document, saying the opposite is not appropriate.

---

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 28 Feb 2020 09:16:35 +0000

Hi

We are currently working on an uploaded version of the draft. You can follow the progress on the GITHUB.

In the meantime, here is an update.

Thanks a lot for your feedback !

The comments that will be "solved" in the next version are commented below.

I think there are some more deep comments that are the following:

==

- Section 3.1 is pretty concise. What type of "transmission"? In intro you say that tunnels are out of scope, which should be clarified and justified here.

Do you want to extend to application protocols as well (with the difficulty of defining what is an application protocol, since we see more and more protocols on top of UDP).

Do you keep multicast as out of scope as there is a dedicated CC that is pretty different?

NK: I think that the current focus of the document is what we describe in the next version of the draft

“The proposed document considers FEC coding at the transport or

   application layer for an end-to-end unicast data transfer.  The

   typical application scenario that is considered in the current

   version of the document is a client browsing the web.  This memo may

   be extended to cases with multiple paths.”

I think even if we focus on transport protocols in some figures, the discussions can be applied to, e.g. QUIC and at the application level.

I am afraid that opening the draft to cases such as multiple path or multi cast may not be relevant at the moment.

Discussions on interactions between multiple path and transport are important but we can hardly mix everything in the current document.

We could still add a ‘wish list’ at the end of the document with multiple path management.

What do you think ?

==

==

There is also the additional idea of how it relates to transport reliability mechanism which is (in theory) out of scope.

[NK] We may have been lost on our path. We ended up comparing the solutions and propose discussions on advantages and drawbacks.

I think the draft is more focusing know on what we added in the introduction :

“Another objective

   is to encourage the research community to also consider congestion

   control aspects when proposing and comparing FEC coding solutions in

   communication systems.  That being said, this document does not aim

   at proposing FEC coding solutions characterization guidelines:

   comparing FEC Schemes without considering congestion control can be

   relevant if the goal is to compare those schemes only.”

The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting.

[NK] Indeed – we should propose more examples.

- I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic.

In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions.

In the second case (which includes François's experiments with tail losses) it's feasible.

[NK] We could indeed add a section on application needs.

==

Nico

-----Message d'origine-----
De : Vincent Roca <[email-masked]>
Envoyé : mardi 18 février 2020 17:08
À : Kuhn Nicolas <[email-masked]>; Michael Welzl <[email-masked]>; François Michel <[email-masked]>; Emmanuel Lochin <[email-masked]>; Nwcrg <[email-masked]>
Cc : Vincent Roca <[email-masked]>
Objet : Re: [nwcrg] New Version Notification for draft-irtf-nwcrg-coding-and-congestion-01.txt

Dear authors, all,

Sorry, it’s a bit long…

Cheers,    Vincent

——————

Abstract:

--------

- I do not understand:

[NK] The text has been changed to :

This memo offers a discussion of

   how FEC coding and congestion control can coexist.  Another objective

   is to encourage the research community to also consider congestion

   control aspects when proposing and comparing FEC coding solutions in

   communication systems.  That being said, this document does not aim

   at proposing FEC coding solutions characterization guidelines:

   comparing FEC Schemes without considering congestion control can be

   relevant if the goal is to compare those schemes only.

- Global comment, title including: using "coding" without any further information, is ambiguous. I'd prefer FEC coding or erasure correction coding, at least in the abstract/introduction.

[NK] The abstract and intro will say FC coding instead of coding.

Introduction:

------

[NK] It has been made clearer in the document. We have also precised what are the tail losses ((i.e.

   tail loss can refer to losses at the tail end of transactions)

- Ambiguous:

   coding solutions.

I'd rather say:

  systems.

Rationals: this is **another** objective; comparing FEC Schemes without considering congestion control makes sense if **the goal is to compare those schemes only**.

[NK] Updated text :

This memo offers a discussion of

   how FEC coding and congestion control can coexist.  Another objective

   is to encourage the research community to also consider congestion

   control aspects when proposing and comparing FEC coding solutions in

   communication systems.  That being said, this document does not aim

   at proposing FEC coding solutions characterization guidelines:

   comparing FEC Schemes without considering congestion control can be

   relevant if the goal is to compare those schemes only.

Section 2:

----------

Or perhaps it is indicated by the use of { and }, but in that case it's not very clear. Using plural is also preferable.

[NK] The figure has been updated with arrows.

[NK] We have adapted the wording based on the taxonomy.

- It is said:

[NK] We have adapted the wording based on the taxonomy.

What exact information is given back to the FEC entity really depends on the use-case, but I like the way it's written in the text: it's some information about what is lost and what is recovered thanks to FEC coding.

[NK] We have added a specific section to detail the rationale behind the different wordings that are shown in the figure.

- It is said:

   (indicated by the horizontal double arrow) between the two entities, There is no horizontal double arrow!

[NK] I hope the text is better now.

typo:

[NK] Thanks.

Section 3:

----------

- Section 3.1 is pretty concise. What type of "transmission"? In intro you say that tunnels are out of scope, which should be clarified and justified here.

Do you want to extend to application protocols as well (with the difficulty of defining what is an application protocol, since we see more and more protocols on top of UDP).

Do you keep multicast as out of scope as there is a dedicated CC that is pretty different?

[NK] This is discussed in the header of this email.

[NK] This is just discussed in the sections describing each case.

- I'm surprised to see "Section 3.3.  Objective of the document" at this moment in the document. Please put it before.

The first two sentences about mixing the CC and FEC channels should also be moved at the end of section 2, it does not belong to the objectives.

[NK] Indeed – we have removed that section and merged it into the introduction.

Section 4:

----------

- I appreciate to see these three sections, but I think they should be grouped as subsections of a single one entitled:

[NK] Done

- There's really an ambiguity about what is coded data: does it include source data packets or not? And why data rather than packets?

[NK] We have improved the wording  with the taxonomy.

This is only a drawback if one is stupid enough to do FEC protection on top of a reliable transport protocol. I'd rather say:

[NK] Changed – thanks.

- This is suggested in the figure ("sending rate or window"), but not detailed in text. There is preferably a feedback between CC and FEC entities.

[NK] We have precised what is sending rate when this figure first appears.

[NK] This comment is discussed in the header of the email.

There is also the additional idea of how it relates to transport reliability mechanism which is (in theory) out of scope.

The case of QUIC and what was already proposed here to let FEC and CC work together is pretty interesting.

- I also think the application (as data source) is potentially involved in the big picture: an application generating a real-time data flow is not the same as an application generating background traffic.

In the first case we could end up with situations where it's just impossible to carry traffic by adding a certain redundancy, given the network conditions.

In the second case (which includes François's experiments with tail losses) it's feasible.

Section 9:

----------

There are security considerations in most documents, because it does change something (which is fortunate) and therefore it can introduce threats.

Here CC and FEC coding rate could be leveraged to create DoS. Although it's not specific to this document, saying the opposite is not appropriate.

[NK] Section updated.