Minutes IETF99: nwcrg
Coding for efficient NetWork Communications Research Group
||Minutes IETF99: nwcrg
NWCRG @ IETF-99 (Prague), Thursday, July 20th, 2017
Minutes (Draft - 2017-07-25)
Minute-taker: Cedric Adjih and Vincent Roca
00- Welcome, administrative and general matters. Goals of this meeting (Vincent
PART I: Use-cases where end-to-end coding or network coding can be beneficial
NC for satellite communications
01- "Network coding and satellites" (Nicolas Kuhn, CNES, and Emmanuel Lochin
Vincent Roca (VR): I appreciate your initiative in setting up this I-D
and the effort made in collecting views/interests
of different people. Having a design team for this topic is
Marie Jose Montpetit (MJM): I have the feeling this I-D will just look
at satellite links while in fact this link is
part of Internet. Also, do you mean NC at the PHY layer or FEC
at the PHY layer?
Nicolas Kuhn and Emmanuel Lochin (NK&EL): Currently deployed system
all use FEC at the PHY layer (DVB-* standards).
But we do not want to focus only on PHY layer FEC coding, we
consider more complex scenarios with multi-gateways, TCP split
connections, etc. It goes well beyond PHY layer.
Victor Firoiu (VF): thanks for the initiative. What are the research
aspects in this work? NK&EL: yes, we want to provide a view of what
solutions could be deployed, both on the experimental and research
sides. VR: you could perhaps make it more explicit with a « research
challenges » section. NK&EL: yes, in ICNRG there is a document
specific to open research challenges and we could do the same here.
NC for ICN/CCN
02- "CCN and Network Coding" (Cedric Westphal)
Also covers NetCodCCN (Infocom'16)
03- "Low latency low loss streaming using in-network coding and caching"
VR: Thomos Nikolaos sent me an email telling me he couldn't join today
but volunteers to participate.
Maybe it would make sense to try setting up a design team as
with the « NC and satellite » topic.
Allison Mankin (AM): it's probably meaningful to have a common template
for both documents. Lots of aspects
about why you are doing this and what are the components could
VR: agreed. There could be a generic part, common to all documents, and
a use-case specific part.
Hitoshi Asaeda (HA): the « research challenges » could be in a single
Cedric Adjih (CA): I'm interested by the topic.
Other NC potential use-cases
04- "Some Network Coding Use Cases" (Vincent Roca, on behalf of Rolf Sperber
Slides quickly presented by Vincent Roca (sorry for not being clear on
what was expected). Lists potential a few domains for potential NC
(high density sensors, train, vehicles, content storage).
05- "Generic Robust Low Latency Tunelling: proposal for a performance enhancing
tunnel" (Marie-José Montpetit, remote) (10')
VR: do you believe it is useful to do re-coding?
MJM: it could be, but we didn't think about it yet.
VR: what is a micro-flow?
MJM: do we want a tunnel to be end-to-end, with all flows multiplexed
into it, or do we want the tunnel to be aware
of each individual flow (i.e., consider micro-flows)?
VR: is there interest? I know there is Akamai, anybody else? I (VR) am
interested as individual. We will ask to the mailing list.
VF: a little bit out of the initial charter, we did not thought about
it so far, but very interesting.
EL&NK: sounds more like a problem of network traffic engineering
than network coding. MJM: agreed. It is more putting NC into a traffic
engineering toolkit. But as it implies the use of NC, it is related to
This work will not lead to new codes, of course.
NK&EL : there are other groups working specifically on tunnelling.
MJM: agreed. If the group believes it is not related to NWCRG, maybe we
could address it within a transport WG. Brandon Williams (BW): with
respect to the network engineering aspects, the codes and their tuning
directly impact the network quality
and the quality of experience for the application. The tuning
of codes for video would be different from the tuning for data
transfers. The focus is on the tuning of the parameters and the
negotiation of the aspects of the codes themselves that have an
impact of network engineering.
NK&EL: much clearer now and we understand the need for it.
VR: let’s continue on the list.
PART II: On the coding side
Low complexity coding
06- "Pyrit: Polynomial Ring Transforms for Fast Erasure Coding" (Jonathan
VR: thanks for making this presentation very understandable, skipping
complex details. CA: you go from field to ring, operation, and go back
from ring to field: is it isomorphic ? Jonathan Detchart (JD): not all
operations are isomorphic, but they are homomorphic most of the time.
CA: why don't you stay in the ring? JD: the representation in the ring
is larger which finally creates problems. So you need to go back.
Morten Pedersen (MP): very interesting. I’d like to know more about the
transforms and their speed. JD: [details the two transforms] from the
field to the ring, it's just a matter of adding a parity bit, and
the reverse transform is about removing this bit.
MP: reminds me of some work on optimal prime field where there was a
mapping as well. I'm impressed by performance.
On the benefit of sliding window codes (network coding?) to IETF protocols
07- "Less Latency and Better Protection with AL-FEC Sliding Window Codes: a
Robust Multimedia CBR Broadcast Case Study" (Vincent Roca)
somebody@Akamai: did you use Raptor or RaptorQ codes?
VR: we used the "old" Raptor codes that are part of 3GPP MBMS standard.
Anyway, Reed-Solomon are ideal
codes and even with RaptorQ, you could not achieve better
erasure recovery performance.
MJM: have you have thought about other convolutional codes, or just
sliding window? VR: we considered the simplest sliding window codes,
those that are described in our TSVWG I-D.
VF: very interesting. You considered fixed rate coding, but other
protocols may also need dynamic rate adaptation, or others may
stream content for ever until all receivers got the content (as
with fountain codes).
VR: we are not considering any dynamic adaptation in this work. This is
a broadcast/multicast scenario, so there's necessarily a
single stream for all receivers and you need to define all
parameters in advance. But with a unicast scenario involving
feedback messages, adding a dynamic adaptation of RLC
parameters would not be a problem.
08- "FEC codes and QUIC" (Ian Swett)
MP: running FEC codes are no longer a problem, even on lightweight
embedded platforms (e.g., smartphones).
You'll find many works including ours confirming this.
(somebody): if you want to test with sliding windows in QUIC, is there
are a good starting point? IS: Going to the implementation would be the
most easier approach. The Chromium one is pretty close to what we are
It's C++, very fast, and recommended. There is another one but
I don't know how up-to-date it is.
NK&EL: we did not understood the CDF drawing. What is the QUIC
window size? IS: It's essentially packet losses per window. The window
size could be different across tests.
It's not exactly what you are used for. The figure itself comes
from 1 week of Google traffic.
VR: I think this is a very important topic. Thanks to everybody and
let’s continue on the list.