Minutes IETF99: nwcrg

Meeting Minutes Coding for efficient NetWork Communications Research Group (nwcrg) RG
Title Minutes IETF99: nwcrg
State Active
Other versions plain text
Last updated 2017-07-25

Meeting Minutes

NWCRG @ IETF-99 (Prague), Thursday, July 20th, 2017
Minutes (Draft - 2017-07-25)

Minute-taker: Cedric Adjih and Vincent Roca

Meetecho record:

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
(ISAE), remote)

        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.


02- "CCN and Network Coding" (Cedric Westphal)
        Also covers NetCodCCN (Infocom'16)

03- "Low latency low loss streaming using in-network coding and caching"
(Hitoshi Asaeda)

        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.
        Presenters: agreed

        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
                be common.
        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 group.
                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
        using internally.
                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.