Minute takers: Marco TILOCA, Javier Alejandro FERNANDEZ
Marion Dumay is a new co-chair, Quentin Lampin is Technical Advisor,
and Pascal Thubert, one of the fathers of SCHC, is stepping down
(round of applause).
LT: ICMPv6 + Universal Options draft is being updated.
AP shows List of documents about SCHC: Framework core + Extensions,
Interoperability, Adapted to (technologies, etc.), Applied to
(protocols, etc.).
AP: SCHC Architecture draft has seen a lot of progress towards
simplified and unambiguous description of what SCHC is /proceeds to
showcase basic architecture (endpoint > instance > context, ...), +
use-case scenarios (multiple instances on an endpoint, ...)/.
LT: +1 for separation of intentions from Compression/Decompression. It's
confusing to have the architecture as it is right now + new study
concepts (domain, etc.) in the same document.
AP: This is the result of discussions, these concepts were already
present but not named. We're documented how to use SCHC for 6LoWPAN,
CoAP/OSCORE, LPWANs, etc. Some things are work in progress.
Eric: There are already many documents to split this one again. It'll be
way simpler to have only 1 document.
MT: Addressed reviews in latest PR(s)... some fixes. Next steps: submit
a new version after merging some pending PRs (3 and 4), and aligning
with wording from SCHC Architecture.
MW: "SCHC Compute Address for Dynamic Addresses": devices use
dynamically allocated addresses (SCHC looses compression efficiency, or
frequent rule updates are required, ...). => IPvx prefix appears
straightforward, while IID is much more invasive/complex.
Eric: Are you sure you never have desynchronized contexts?
MW: Have a hash (?).
LT: I didn't understand why not use a matching list for new addresses;
we're also working on management (push information i.e. coreconf
management). Another point: prefix length could be set to 60 etc. Let's
talk more in interims.
In the chat:
LT: @Martine great job, do you have some results on compression ratio ?
ML: No, performance wasn't the goal of the work, I implemented it for
(see my other mail to the mailing list; or my talk from iotops ;-)). But
should at least for DTLSv1.2 I should be able to generate some
statistics from some of my traces. For DTLSv1.3 some back of the envelop
calculations should suffice (for DTLSv1.2 probably too). The
implementation was based on
https://ieeexplore.ieee.org/document/10051055. It has some numbers, but
the ruleset there is unnecessarily rigid IMHO.
LC: Problem is SCHC context scalability issues. Proposed solutions are:
Rule referencing CDAs (reference rules/fields with overrides), Dynamic
Rule Fragment Selection/Branching (match-mapping, match-rule). +
security considerations (circular references, enforce limits on
reference depth, context integrity).
AP: Good work. A context expressed with CDAs... represent the same in a
more compact way... Does this require a new Data Model? From the outside
world it can be seen as compliant.
LC: Not sure this works on Dynamic... We can work on that...
AP: Interesting to have 2 data models: compact vs non-compact?
QL: Objective is to discriminate sessions (.e.g. multiplexing SCHC Data
Units to the right SCHC Instances, etc.). VOICI is a SCHC Control
Header, propsed as a dispatcher.
VOICI is a proposed minimal encapsulation header that sits in front
of a SCHC to multiplex multiple sessions over the same link. VOICI
is essentially a lightweight shim header for dispatching and
demultiplexing SCHC traffic over shared constrained links with minimal
overhead (Adaptive & SCHC-Compressible).
LT: VOICI compression rule already exists in SCHC, I don't see the
interest, it's a SCHC Header + Control Header, the rule gives the
serialization of these fields;... We don't have to go to a new protocol
QL: I agree it's very similar, the key point is we need a way to
describe this.
LT: Why do we have V? I think you're pushing complexity (new protocol on
top of SCHC).
QL: This won't be part of the architecture, it's a proposal. You would
still need to write the schc rule for it.
LT: But you can fit everything / solve the need within the existing SCHC
framework.
We move on; we'll continue discussing in interim's.
SS: Under which conditions can this be done, etc. Explaining why we did
this (metadata overhead for very small packets or expensive links), but
QUIC is already compact: savings should be larger than Rule ID + framing
+ residue. => We don't gain much. Savings require known fields, traffic
patterns... QUIC compression is too niche; better to focus on outer
packet headers (IP, UDP) and accessible QUIC header fields.
LT: A way to compress CORECONF: we propose to move the assigned SID
range to a small negative number on the wire. Very positive impact
on SCHC (require new MO/CDA (translate_sid)).
MD doing introductions
AP: Welcoming (again) MD as co-chair and QL as technical advisor.
AP: PT is an invited speaker; remembering beginning of SCHC
EV: Thanks for your contribution, also in 6lo.
PT: Thank you all, I was confident about the achievements of the group
MD: There are some expired WG documents; we expect updated versions of
some of those, while others are currently on hold (e.g.,
-universal-options and other ones related to SCHC data models)
LT: On ICMPv6 and -universal-option, there was a lot of work on the data
models. We should start more official work about the evolution of the
data models, building on those initial works. I can have something for
the interim meetings.
AP: Recap on the status of the SCHC architecture work. Documents are
partitioned according to this view: framework + extensions;
interoperability; SCHC adaptations; SCHC "applied to". They are not all
(meant to be) WG documents, but they are all useful data points.
AP: Yesterday we had a side meeting on this. The desing team is done
with this work and now we present the result.
AP: The design team has focused on revising the -schc-architecture
document, largely about key concepts and terminology in SCHC. Not
necessarily final and perfect, but we've made progress, with examples
for different setups with different complexities.
AP (p4-6): Going through key concepts in examples (e.g., "Dispatcher"
and "Discriminator"). The Dispatched shouldn't need to know about SCHC
rules or SCHC-related things, or you risk a chicken-and-egg problem.
AP (p7): "SCHC Datagram" to be renamed as "SCHC Data Unit", removing the
case the RuleID is followed by a Control Header, followed by other
fields an payload. If the Control Header is present at all, it can only
be before the RuleID. The document VOICI is proposing a possible format
of Control Header.
AP (p8): The next version should cover more in detail the Control Header
and its format.
AP (p9): After revising -schc-architecture, we checked for any possible
conflicts/inconsistencies between that document and other SCHC-related
RFCs and Internet Drafts. No issues with the RFCs. Almost all the other
documents are "easy"/"trivial" to be translated adapted, by fixing some
terms. A few other documents require a bit more attention. We have
generated a diff for the document authors to follow for aligning those
documents to the latest -schc-architecture. The diffs with an
explanation are available in the GitHub repository of the WG document
-schc-architecture. We would like to complete the document by the end of
the year.
AP (p10): The immediate next step is producing v -07 with the things
just presented.
LT: Appreciate the separation of concepts. You want to document SCHC for
people that come, but we are also introducing concepts like "Domain".
Maybe it's good to have two documents: one describing things as they are
now, and one describing where we want to go.
AP: We are mostly covering things that were discussed last time we met
in Montreal, where we converged on a resolution. Many concepts were
actually present all along, just without a name. We are actually not
done yet, with a few things to fix.
EV: This WG is already loaded with many documents, so it's way simpler
if there is a single document describing all the concepts and terms.
Then it's up to you.
AP: Please read the draft. Authors of other documents, please align
those according to the diff with -schc-architecture.
MT: presenting the change since -06 version
MT: Still pending: PR addressing the Yang Doctor review (remove the YANG
module and related text); PR from Laurent about always having something
in FL in Field Descriptors (making the related text consistent).
MT: Next steps: merge the two PRs; align with the terminology of
-schc-architecture, per the related diff (see previous presentation);
submit version -10, which should be ready to send to the IESG.
MW presenting
MW (p3): Problem: applying SCHC to mobile network traffic. Devices
dynamically acquire IP address implications. SCHC rules have to be
independent from device addressing.
MW (p4): Challenges on addressing devices in mobile networks
MW (p5): Approach to compute addresses to use in the CDA of Field
Descriptors.
MW (p6): The IID is also compressed. If you experience a collusion, you
redo the hashing.
LT (on chat): lorawan has something like this to compute IID
MW: Any interest about solving this problem? I know it's pushing the
boundaries about the "static" header compression.
EV (as an individual): The two endpoints are building the same table.
Are we sure that the two endpoints are synchronized?
MW: We need to ensure that they agree.
EV: I like the idea. I'm a bit uncomfortable on the IPv6 side. Have a
look at 6man.
MW: You need a solution to handle changes.
AP: So the rules are static but the table of addresses is not fully. You
can better specify the requirements for the address table. You need to
say what needs to happen when there is an update, so that the endpoints
stay in synch and things keep working.
LT: We need to work on addresses in the rules. Why don't you use a
matching list on your addresses, and just have that list in the rules?
On the management, we can converge to a prototype where we use CORECONF.
LT: In the rules, you can indicate a length, that would fit.
MD (on chat): (chair hat off) @Magnus many thanks for this contribution,
SCHC for mobile networks is an important use case and supporting dynamic
allocation adresses is mandatory
LC presenting
LC (p2): IPR disclosure
LC (p3): Problem: poor scalability in number, size, and variability of
SCHC rules.
LC (p4): Two proposed solutions: i) a new type of CDA can refer another
rule; ii) fragment branching with dynamic composition
LC (p5-6): Examples of the first solution
LC (p7): More details on branch CDA
LC (p8-9): Examples of the second solution
LC (p10): Security considerations: rules must be free of circular
dependecies, limited in terms of reference depth, and consistent also
across updates
AP: Very interesting. It's also related to representing the Context in a
compact way. So this is a way to use (MO, CDA) in a less verbose way
than we do today. Is that a new data model? Can it still be seen as
compliant with RFC 8724?
LC: That would work, you want to avoid a rule explosion. With the
branching approach, things really become runtime-relevant.
AP: It would be interesting to have two data models: a compact one and a
non-compact one.
LC: We should investigate this.
MW: These problem are real and being less verbose is important.
JF: This is very different from hierarchical rule parsing.
(will continue on the mailing list)
QL presenting
QL (p3): Recap of VOICI background/motivation
QL (p4): Overview of what gaps VOICI fills in other protocols compressed
with SCHC
QL (p5): VOICI as a possible format of Control Header for SCHC
QL (p6): VOICI fundamentally enables a Dispatcher based on the provided
Control Header.
QL (p7-12): Examples
QL (p13): VOICI can actually be employed beyond SCHC
EV (on chat): @Quentin please insert SCHC in the filename
LT: About p8: the SCHC rule here is what we already have in the SCHC
header. This seems more complex than the semantics that we had before,
with SCHC Header and SCHC Control Header. This might not be needed.
QL: This is similar to what is in the architecture.
LT: What do you do if V is not good? What is the reaction?
QL: It means a new version of the protocol. Like for other protocols,
you discard the packet if you don't understand it.
QL: You may wonder why we have V? It can help for protocol evolution.
LT: I think you are pushing complexity. If you agree on the rules,
that's where you put the information you want.
EV (on chat): Laurent is right, you will need to add text about what to
do when V is received as 1
QL (on chat): Sure, will do.
LT: This is not for the architecture. This is a proposal of Control
Header, consistent with the blueprint described in the architecture. Of
course you still need the SCHC rules. In your case, you may not need the
V bit, but this has to be written somewhere.
MD: Let's continue the discussion on the mailing list.
AP: The architecture document is Informational and it admits a Control
Header. Different Standard Tracks documents can specify different
Control Headers. Some technologies like Ethernet need a Control Header.
SS presenting
SS (p2): QUIC is already pretty compact.
SS (p3): Design space on how SCHC can be used in QUIC
SS (p4): Results about achievable size reduction
SS (p5): This is all feasible although QUIC is already very compact;
this is an optimization of an optimization. This is more interesting if
taking place in the context of rule maangement (e.g., with CORECONF)
EV (as an individual): QUIC has a padding function. Is this covered in
your draft?
SS: Not paid particular attention to that.
MW: Padding is available but not used that much.
MW: What about compressing the Connection ID?
SS: Rules are static but they can be updated leveraging the stable
Connection ID.
MW: That seems to be the only remaining thing to compress.
LT presenting
LT (p2): This is a way to compress CORECONF messages.
LT (p3): Example with delta-encoded SID
LT (p4): Proposed to "move" SID, with a translation to small negative
numbers, since they are encoded in few bytes in CBOR.
LT (p5-8): Example with performance results.
LT (p9): This was presented at a CoRE interim meeting. The part about
SID translation itself seems pertaining to CoRE, while the specifics of
SCHC are more for the SCHC WG.
LT (p10): More comprehensive example with SID allocation and translation
into private SIDs.