NOTE - multiple notes were taken by Esko Dijk, Christian Amsüss, but as
the notes format was mixed, lots of copy-pasting was necessary to merge
the notes, so in the HedgeDoc the names of who actually took the minutes
may be changed (e.g. to Alexander Pelov and/or Pascal Thubert). See
notes history for attribution of notes.
Chairs
o Alexander Pelov
alexander.pelov@imt-atlantique.fr
(in-person chair)
o Pascal Thubert
pascal.thubert@gmail.com
(in-person chair)
Notetakers
o Esko Dijk, Christian Amsüss
Responsible AD
o Eric Vyncke
Room: Liffey MR 2
Agenda: on datatracker
Meeting documents: on datatracker
Meeting material: on datatracker
Meeting link: Meetecho Link
On-Site tool: Meetecho Link
Live Minutes: CODIMD Link
LT: SCHC Access Control, waits for architecture draft
Laurent: we will continue the work on the draft ... once we have a good
view on the architecture.
Laurent: we now have a tutorial on SCHC, see vm.openschc.net - in a
virtual machine.
Includes also the "Book of SCHC". Also, videos. Also, a MOOC.
Pascal: very well made and beautiful video.
PT: Highly recommended video; expert teaching.
Pascal: Discussion of SCHC protocol numbers draft - see slide. Proposed
to drop the UDP port, not aware of any need for that.
Mirja raised the issue that this should be part of the architecture.
But that is unwanted delay, if we do that. Prefer an informative ref to
the arch doc.
Eric Vyncke: a WG-adopted draft is enough to get an early allocation.
Pascal: happy to ask for early allocation.
Eric: yes, easy to get IP protocol number early.
Eric: don't agree about not needing UDP port number as it can be useful
to traverse the ugly NAT including NAT64
Pascal: don't need UDP port, not planned in current architecture. Joe's
text was hard to parse for me. (about IP in IP)
We're not ready for UDP clearly. Let's not delay IP.
PT: requested UDP port, but reviews suggested that the draft is not
ready. The need of UDP port is not proven today.
PT: proposal - drop this part
PT: question about moving the protocol number / ethertype to
architecture document, but doesn't seem the right way forward
EV: WG adopted draft is enough for early allocation.
PT: Even for IEEE?
EV: Not sure.
EV: It's easy to get an IP protocol number (got one for a protocol
that's barely used yet, compared to SCHC which is used)
EV: use-case for UDP is to traverse NAT
PT: both reviews from IESG said this is not the right way to do. Not
sure we agree, but we follow IESG, and at this stage not ready
Laurent: changed the draft name to be more clear - it's about ICMPv6
compression.
LT: examples
PT: there are more generic echo functions for ICMPv6 in 6MAN Interesting
feature, we need to monitor it.
Pascal: just to mention, work in 6man about more generic echo function.
Interesting feature, let's monitor it - a more generic ping.
PT: we can send the compressed version to the device (see if this should
be done)
LT: example with ICMP message being generated by the SCHC Core, if the
device doesn't support this port (the SCHC Core can know this from the
SCHC Rules)
Laurent: ok, currently we only do the regular ping. Interesting to have
also other debugging mechanisms.
Laurent: we removed 'Action' from the draft, have to discuss this.
Our use of this is for proxy-ping. E.g. proxy saw the device in last 5
mins, then respond to ping on behalf.
Laurent: we have to define 'action' in architecture document.
LT: Action for architecture
(no questions)
Alexander: 'ships in the night' slides - reassembly process can remain
unchanged, with FEC process acting independently/alongside.
FEC info can be used to recover lost tile(s).
(p26) operation flexibility to send FEC more often.
Pascal: there's work at the Detnet WG to add diversity in transmission.
SCHC could become a good complement for RAW architecture.
(p29) Different rules can work independently on the single way of
fragmentation.
EV: Why do on tiles and not on fragments?
AP: …?
Carsten: using codes here to protect the original exchange.
AP: (on comparison slide) Expecting to have both modes in the end due to
different properties.
LT: (p15) To me that's two faces of the same thing, maybe there can be
convergence. (1 over 2 v. 3 over 5)
AP: okay
EV: Curious, are there numbers and measurements on how many fragments
are lost in a row?
AP: Sometimes it can be a lot, like 30%. We want to have a parameter
that the operator can tune. For some classes of devices, it may not be
needed.
EV: More about amount of consecutive packets lost in a single bad event.
AP: If you lose 5 consecutive packets, and 2 losses are protected, it's
not working.
CB: "No need for FEC emission strategy", I'd say "No opportunity for"
and put it in cons. Haven't read draft, but from presentation,
FEC-before-Frag sounds totally useless, just another interop headache.
PT supports that statement.
IP: Have you run simulations?
AP: There was a research paper stating that doing a XOR of ... is good
enough. Wanted to implement and run it.
CB: Reminder of "why FEC": multicast (where receivers lose different
fragments), and when you can't wait for or don't have path for NACKs. If
none of them apply, you do retransmission.
PT: Third reason when operating on graph rather than point-to-point is
to use it for network coding – when doing network flooding (?) - maybe
one path is interrupted. Adding diversity over diversity, even over
technologies.
LT: For applicability. If you talk about electric meters. On deep space,
maybe need stronger FEC.
MT presenting.
CB (p4): ISO/IC 80000 part 3, says byte is "o" / "B", and bit is
abbreviate "bit" (not "bit" because not rely on uppercasing). Please use
"bit".
MT 8824 does this. CB: Then fix it
MT on page 6: File erratum on 8824, or does bis suffice?
(no opinions from room)
MT: I'll do that then.
MT: Mechanism of token could be used 1:1 with same motivation for OSCORE
PIV. Could be introduced as a new feature -- worth adding for
consistency and performance.
(LT nods)
MT (p9) more questions to go to list.
For chairs: Please let's transfer repo into WG to keep issues.
MB presenting
MB (p3): Mars and Moon similar b/c far away -- 7 orbiters can cover
moon, and it's still cheaper (??)
MB: Recent change: yesterday, in a study, SpaceX proposed starlink over
Mars
MB: Stations store frames until path is clear, currently at L2. They
forward bags-of-bits, no knowledge of frames. All point-to-point.
MB (p4): More details in deepspace side meeting.
MB (p9): Newer rovers get downlink from Earth but uplink via relay.
MB(p11): Laser Gbit are near future.
MB(p11): Bit error rates not measured.
PT: As CB mentioned, FEC for long roundtrips. …. Multipath over
constellations becoming relevant, more FEC applicability.
AP: Charter discussion yesterday focused on QUIC. Does that exclude
CoAP?
MB: Looking at whole IP stack, potentially multiple protocols. Was asked
to not talk about network management (yet): trying not to boil the
ocean. CoAP makes sense to me, but let's start with sth smaller in
scope. (Does NTP work there? There are some hopeful signs). We'll look
at profiles, not building protocols.
Rodrigo Munoz-Lara presenting remotely.
RM: this presentation was a summary of what we added to the new draft
version.
AP: is there a specific LEO constelation that was used as baseline
RM: the SCHC proxy is not considered L2 technology.
PT: personally I love this work, any plans to continue in IETF with this
work and write a document ?
LT: thanks for the presentation. In the architecture there's ICMPv6 - do
you need to compress this, in the future?
MH: yes.
LT: can we apply SCHC on ANIMA messages?
MH: uses HTTP, TCP, IPv6. These are all headers that we can apply SCHC
on. If more compression methods are defined in the future we can
compress even more.
Antoine Fressancourt: on BRSKI - it seems based on a secret at
manufacturing time. How is this put in the device?
MH: it's put into the device, by an entity that communicates with a CA.
ED: it's an IDevID that can be provisioned into the device in many ways.
AM: need for a solution to compress TCP, RTP or other protocols that
have the notion of a "flow"
LT: once you've learned UDP specifics (port, ...) then we can enhance
the compression of this flow.
PT: how to sync the 2 sides?
LT: we have coreconf to set up new rule on the other side. Rules can be
removed, e.g. after 1 min of no use. Need same set of rules on both
sides.
CB: same question, different words - state management is going on. We
had 40 years of header compression. Trying to understand how this state
mgmt fits with existing schemes of state mgmt. We should come from state
mgmt point of view. We need an architecture for state mgmt - coreconf
may be an implementation of it.
LT: main difference is that we don't change the compression phase.
Management just adds new rules.
PT: but, that still depends on the state mgmt Carsten was talking about.
CB: the 's' in SCHC stands for static?
LT: static context. We have a synchronized context, so it can remain
SCHC.
Show of hands question for work on concept of "Action".
12 yes, 2 no, 2 no opinion.
AP: thanks for coming and staying on Friday.
Carles: thanks for authors for all the work on SCHC architecture. There
are some cross-Wg dependencies. It would be great to have a version 0.3.