Minutes IETF110: nwcrg
minutes-110-nwcrg-00

Meeting Minutes Coding for efficient NetWork Communications Research Group (nwcrg) RG
Title Minutes IETF110: nwcrg
State Active
Other versions markdown
Last updated 2021-03-24

Meeting Minutes
minutes-110-nwcrg

# IETF 110 NWCRG Meeting Minutes (v1)

* [Datatracker](https://datatracker.ietf.org/rg/nwcrg/)
* [Github](https://github.com/irtf-nwcrg/rg-materials/)

## 1- nwcrg@ietf110-hackathon

CANCELED

## 2- nwcrg online meeting

Online meeting on Thursday March 11, 2021, 14:30-15:30 (UTC) Thursday Session II
[Time Zone
Conversion:](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210311T1430)

------------------

Participation will take place through Meetecho (please connect in advance):
    - [Meetecho participant
    guide](https://www.ietf.org/how/meetings/110/session-participant-guide/) -
    [links to Meetecho
    sessions](https://datatracker.ietf.org/meeting/110/agenda)

------------------

#### 00- Welcome, administrative and general matters
(Chairs) (10')

### Updates of existing works:

#### 01- "BATS Coding Scheme for Multi-hop Data Transport" I-D
(Raymond Yeung) (10+5')
(https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/)

Watson Ladd (Cloudflare): very interesting work. How to advance the draft and
have it published on time? RY: we have the feeling it's pretty ready for
publication. VR: the newly added section 4 is very well written and clear, and
the same it true for the security section. I need to read the specifications
part but otherwise I'm very happy with the way this document progressed. Just a
comment for section 4: if you can make it a bit more neutral, it would be fine.
RY: yes, no problem. Dave Oran: what happens when a RG closes, is that we put
the research group in sleep mode until the last document has been through the
whole process and is published, and only then we formally close the group. VR:
I'm quite confident we can have a RG Last Call very soon.

#### 02- "Coding and congestion control in transport" I-D
(Nicolas Kuhn) (10+5')
(https://datatracker.ietf.org/doc/draft-irtf-nwcrg-coding-and-congestion/)
Update of the document and new experimental results.

(bad audio quality)
NK: open issue #56
VR: it’s pretty easy, add a few details like: "(e.g., block versus sliding
window, small versus medium or large block sizes, possibility to solve a subset
of the linear system)" NK: open issue #57 VR: here also it's easy to address,
add a reference to the existing RFC8681. Parameter derivation is more than just
a matter of "amount of redundancy to add", it's more complex than that. You can
achieve the same reliability for a given loss pattern by using fewer redundant
packets, just by changing the nature and usage of the FEC scheme, and if you
can do all of this without increasing latency, then you win. NK: open issue
#58: we agree and will update this section. Markus Amend (Deutsche Telekom):
I'm co-author of three multi-path TCP documents. Do you have a reference
implementation? NK: Depends. François Michel has an implementation of FEC in
QUIC. MA: It could be a great opportunity to bring this work to the MPTCP
group, you're welcome. Another question is about synergies with ICCRG. NK:
let's continue on the mailing list, but yes, there are overlaps and this is why
I sent the email. VR: the document is progressing well, and I'm confident we
can have something ready soon. Thank you.

### Others

#### 03- "About latency/reliability for block and sliding window codes"
(Morten V. Pedersen) (10')

MJM: We know that for quite a long time. Have you done more research on this?
MVP: Yes. A first topic we are looking at comes from the fact that sliding
window codes do not always behave better than block codes, especially when the
repair rate approaches the channel loss rate. Sometimes you can end up in a
situation where repairs are almost useless with sliding window codes, whereas
with block codes, blocks being independent from one another, you can recover
from a bad situation more easily. We are looking at situations where the repair
and loss rates are close to one another, and how to manage the sliding window
in that case, potentially getting closer to block codes. Another topic is how
to address situations where you have links with different latencies. In that
case, the packets sent over the slower link cannot include as many packets in
their repair window as those sent on the faster links. Content aware coding is
yet another topic. You can easily get a latency penalty if you don't make your
coding window adjusted to the source flow when this source flow is of variable
bit rate. A fourth topic: reliability techniques are usually split into either
ARQ or FEC. Yet protocols could try to take the best of both, depending on the
experienced latency. Those are some of the directions we're looking at. Watson
Ladd: really interesting. How close to the channel capacity are you? MVP: there
are tradeoffs here. If you use FEC underneath the transport protocol, you can
effectively mask all losses, but it comes with an increased bandwidth. Yet
sliding window gives you the best tradeoff between reliability and overhead,
much better than Reed-Solomon codes most of the time. VR: This discussion was
very interesting. During next meeting, we'd be very interested in having more
insights on these aspects.