Minutes IETF105: nwcrg
Coding for efficient NetWork Communications Research Group
||Minutes IETF105: nwcrg
IETF 105 NWCRG Meeting minutes
nwcrg@ietf105-hackathon: Sliding Window FEC (SWiF) codec project
Saturday and Sunday, July 20-21, 2018, starting at 9:00
- [Github swif-codec repo](https://github.com/irtf-nwcrg/swif-codec)
2- nwcrg meeting@ietf105
Friday, July 26, 2019, Morning session I, 10:00-12:00
Minute taker: Nicolas Kuhn. (thanks a lot to you, Nicolas)
#### 00- Welcome, administrative and general matters
NB: FECFRAME-ext/RLC/TinyMT32 standardisation @ TSVWG: three documents
entered RFC Editor Queue.
Comment (Dave Oran, ICNRG chair hat): The base protocol stacks for CCN are
published for RFC. We have a stable base to do the binding with network
coding. We should change the RFC version in the documents.
#### 01- Hackathon feedback: Sliding Window FEC codec project (SWiF Codec)
The goal is to design a reference and open source free codec for sliding
window schemes. Another goal is to challenge the generic FEC API.
Achievements of the hackathon are changing the licence, the encoder is
almost done and the decoder is in progress. The demo C-language
application is almost done and the python wrapper is in progress. As
expected the generic API was challenged and some corrections have been
identified. A goal is to go for re-encoding starting from IETF107
Q (Carsten Bormann): How would you characterize the performance? Is it a
proof of concept?
A: Yes, goal is to have a POC. Q (Carsten): What level of performance
are you expecting?
A: Lots of improvements could be envisioned. The objective is to have
something functional and open source. If anybody further improves the
codec raw performance and releases the source code, that would be great,
but it's not our goal.
#### 02- "Status Network coding and satellites I-D"
RGLC process: comments from John Border and Lloyd Wood and Vincent Roca.
See the updates on the slides and the draft
Q (Dave Oran): in or above network layer (above means no re-encoding in
A: both - and the document is clear about it - no layer 2 coding.
Q (Stew Card): what are the "C" is the architecture picture?
A: this is where we could put the coding.
Comment (Vincent): Since you sent your email to the list after updating the
I-D, no comment on the two open issues has been received on the list.
Please make it clear that you want to close the issues and send it on
the list. Then address the comments recently received from Stuart Card
and we'll start a new RGLC.
#### 03- "Update of the Coding for QUIC document"
Q (Dave Oran): Do you have senses whether one scheme is more relevant
for multipath or not?
A: Have to look more carefully, but the new per-packet solution is
probably more suited.
Q (Dave Oran): Based on your current coding, you may want to adapt the
level of coding depending on the feedbacks in RECOVERED frames received
from the client. Have you considered it?
A: RECOVERED frames might be used to piggyback information to the server
and help the server to adapt the coding scheme. This was not the
rationale but could be doable.
Q (Stuart Card): Be cautious about not protecting ACK - it may have
A it is something we discussed between us, it seemed to be meaningful,
but we can change it if needed.
Q (Dave Oran) Seems oriented towards systematic codes.
A: We can avoid sending sources packets, it is not a big deal. It's
Q (Dave Oran): I do not need to consider repair packets in some
implementations. A: (MJM) it is a systematic code because FEC helps
providing reliability, and it is more an evolution of existing QUIC.
Q (Dave Oran): Just consider non systematic codes in case.
Q (Brandon Williams): I do not have a clear indication whether this
approach works with the API document.
A: These are separated documents for separate aspects - there may not be
much dependency between the two.
Q (Brandon): Some QUIC orientations may impact the API document - just
Q (John Border): There is a non systematic code that could be relevant
for satellite use case.
Adapting the coding to , e.g., rain fades could be relevant.
A: It can be done with sliding window schemes. We want the design to be
Q (Stuart Card): compatible with Hybrid-ARQ type I and type II?
A: Trying to assess the difference between the two versions of HARQ.
A: the constraints is related to the sliding window scheme that may not
have the packets in the buffers to retransmit already sent packets.
Q (Dave Oran): The N bit seems redundant with S bit, no?
A: Adding the N in the first chunk only is optional at the moment. We
need to go deeper in that.
A: In any case we need to clarify many details before going to the QUIC
#### 04- "Coding for QUIC Reference Implementation"
(François Michel - remote)
Q (Vincent Roca): How any implementations do you currently have?
A 3 versions at the moment.
Q (Vincent Roca): Which ones are you going to keep?
A We plan to go on with QUIC-GO and SIGCOMM versions
#### 05- "Another FEC for QUIC Implementation"
(Mihail Zverev, Ikerlan - remote)
Q (MJM): We do not know which QUIC+FEC is best. Merging the solutions
may not be a good idea. When we started to work with Google, we were
going to let operators use the coding solution they want. I do not think
there is a way to efficiently merge the FEC solutions.
Q (MJM): The fact that you are coding after the encryption, repair
packets can be seen on the wire. How would you consider security
A: Dealt with QUIC - you may not see whether the packets are repair
packets or not. But we need to further look at that.
Q (Nicolas Kuhn): You may want to consider RTT of 500 ms, 20 Mbps
(download) and 5 Mbps (upload) for the SATCOM access.
Q (Michael Welzl): Relationships between your solution and congestion
control. You are not changing the congestion control within QUIC. Do you
assume losses do not play a role?
A: We report the losses.
Q (Michael): Will have to check the details in the paper.
Q (Brandon Williams) The characteristics you want from the network and
the need of the application may not be accessible with encrypted
A We can see what packets are reliable or not. This implementation is
embedded into QUIC, so we can see the priorities.
Q (Brandon): Can you selectively apply FEC between different streams?
A At the moment, no, FEC is applied to all traffics. Q (Brandon): Do you
plan to work on adapting the FEC when needed?
A: This is not what we look at the moment.
Q (Brandon): It is gonna be important. It will come up in the
discussions for FEC in QUIC.
Q (MJM): There's lots of work on interaction between CC and coding. At
the moment, you correct all the losses and the CC does not know the
nature of the losses. This is particularly important in congested
network where congestion losses would be recovered with the proposal. If
you get into complicated architectures with various segments
characteristics, things would be more complicated.
#### 06- "Links with other Groups and Initiatives (COINRG, ICNRG, LOOPS)"
Q (Carsten Bormann): This is not hop-by-hop it is meant to be used on
A: Yes, I was meanig path segments.
Q (Carsten): FEC is only one option, retransmission is another. The main
point is "don't look, don't touch", we do not care about the protocol
that is used.
A: There is a QUIC based solution that can be looked at.
Q (Carsten): In LOOPS, we do not look at the host.
A: There is collaboration going-on. NWCRG ended up as being a research
group because IETF was not ready. But the group focuses on real world
deployment. The type of work described in LOOPS is already being
deployed and exploits FEC. I am talking about collaboration between a
research group and a (potential) group.
Q (Carsten): There is something that can be standardized in LOOPS.