# Interim SCHC #12 2024 {#interim-schc-12-2024} ## WG info {#wg-info} * [Charter][1] * [Documents][2] * [ML][3] ## Meeting Information {#meeting-information} * Date and Time: [September 3rd, 2024, 7-8am DST, 4pm CEST][4] * Agenda: [on datatracker][5] * Meeting material: [on datatracker][6] * Meeting link: [Meetecho][7] * Live Minutes: [Note-takers Link][8] * ical: [ICS][9] ## Agenda {#agenda} ### \[16:00\] Administrivia \[10min\] {#1600-administrivia----------------------------10min} * Note-Well, Scribes, Agenda Bashing * WG & documents Status * Lead by: Chairs ### \[16:10\] SCHC over network prone to disruptions and Proxies \[10 min\] {#1610-schc-over-network-prone-to-disruptions-and-proxies--10-min} * Presenter: Pascal Thubert ### \[16:20\] Deep Space BoF and SCHC \[5 min\] {#1620-deep-space-bof-and-schc-------------------5-min} * Presenter: Laurent Toutain ### \[16:25\] IESG Reviews of draft-ietf-schc-protocol-numbers \[10 min\] {#1625-iesg-reviews-of-draft-ietf-schc-protocol-numbers-10-min} * Presenter: Pascal Thubert ### \[16:35\] SCHC Architecture \[20 min\] {#1635-schc-architecture-20-min} * Presenter: authors ### \[16:55\] AOB \[ QS \] {#1655-aob---------------------------------------qs-} ## Meeting minutes {#meeting-minutes} ### \[16:00\] Administrivia \[10min\] {#1600-administrivia----------------------------10min-1} * Note-Well, Scribes, Agenda Bashing * WG & documents Status * Lead by: Chairs AP doing introductions. Some agenda bashing already happened on the Deep Space slot. AP: We'll request a slot for SCHC at IETF 121. At IETF 120, we were quite tight we 2 hours, so we think that 2 hours is a good choice this time too. Any thoughts? LT, CG, AM (on chat): +1 AP: We'll have regular interim meeting until IETF 120, the last one on October 29. AP: Status check of the WG documents. LT: For me, the OAM document is stable and waiting for comments. There were mistakes in the previous version and its examples, but we fixed those and we removed the action part. AP: We will start a WG Adoption Call. AP: We can use the next interim meeting for the topics of access control and PPP. ### \[16:10\] SCHC over network prone to disruptions and Proxies \[10 min\] {#1610-schc-over-network-prone-to-disruptions-and-proxies--10-min-1} * Presenter: Pascal Thubert (no slides - discussion only) PT: The described proxy is more a usual transport proxy that "terminates" the transport on one leg and resumes the tranport on the other leg. How and how much do we want to define/expand this concept here? How do we put "proxy" and "gateway" in relation with one another? PT: the SCHC proxy terminates fragmentation, which may take a long time if you go over interstellar networks. We also need to think in terms of placement in the architecture. AP: Is it only about fragmentation or also about compression? PT: Fragmentation is just one possible thing, for big packets (if actually so and needing fragmentation). PT: The intention is to have a proxy for everything, so its functionality is for this document. AP: We did considered a proxy with two different TCP connections on the two different communication legs. Can we use SCHC here involving two protocols when timing is different? PT: Yes, that's the whole story. The gateway is the beginning of that and focused on Layer 3, but the whole thing where the proxy resides takes care also of Layer 4. LT: Not clear to me when you call it a proxy, if you do fragmentation without compression. PT: You slowly get packet fragments until you can reconstruct the whole packet. That's also applicable to a CoAP proxy. AM (on chat): The section on OAM draft that was deleted was also a proxy LT: It can be useful for keep alive messages to have conditions that influence the keep alive behavior. LT: Now that everything is encrypted on the Internet, that's also something that becomes more complicated to achieve. AP: Would you like to send a mail to the list asking for feedback? What's the next step? PT: Not asking for a new document. The architecture document can benefit of a discussion about proxies. LT: Agree to have a discussion on proxies in the architecture document. But maybe it's just not the proxying functionality that you have in mind. PT: That's something to be explained and it depends on what layer(s) you want that entity to operate. The architecture should show that, and maybe give names to those variations. AP: I suggest to bring this to the mailing list, to have more discussion, and understand better what can go to the architecture draft and what can actually deserve to be in a separate document to consider a dedicated standardization work. ### \[16:20\] Deep Space BoF and SCHC \[10 min\] {#1620-deep-space-bof-and-schc-------------------10-min} * Presenter: Marc Blanchet, Laurent Toutain LT: Marc and I has a side meeting in Vancouver. I mentioned what we did in LPWAN networks. In Deep Space communication, RTT is the enemy (4-20 minutes for Mars). If we lose one SCHC packet we don't lose context synchronization, which is very efficient. LT: Following that meeting, we plan a BOF for IETF 121. Can we have SCHC with QUIC? That would improve the goodput of the link and probably improve performance. LT: communication to the moon - most important thing would be bandwidth. MB: Mars is our benchmark, but a first concrete step considers the moon as more feasible in the short term. Mars: 20-45 minutes time. Orbiter going around Mars will be out of reach if it is behind Mars, but probably you can use a rover to communicate with it. Your RTT can go from 20 min to 6h if your orbiter is not in line-of-sight. 25 years ago some studies concluded that IP is not the right paradigm. The DTN WG defined a new protocol stack - Bundles. Moon is few seconds away, with just some slight modifications, most of our protocols will work. Problem is that until you make a full constelation of sattelites, you may have communication interruptions. IP to celesteal things :) will be connected. Deep-space links are point-to-point links. The inital plan was to use ROHC, but SCHC is probably going to be more suitable. We can use UDP-based stacks, such as CoAP. Key output in terms of WG working together, is that there will be the need to use SCHC profile for QUIC. At least SCHC profile for UDP. A side meeting an year ago with ~50 people or so, with presentations by Carles and Laurent. MB (on chat): Online resources * https://mailman3.ietf.org/mailman3/lists/deepspace@ietf.org/ * https://deepspaceip.github.io AP: That's interesting. Thinking of Mars, we need to figure it out. But for the moon, it is very specific. It also fits with the topic of networks prone to disruption in the other document. The issue of timing is the main one. AP: We'll have to include your BOF in the list of conflicts when requesting the SCHC session for IETF 121. ### \[16:30\] Early Reviews of draft-ietf-schc-protocol-numbers \[10 min\] {#1630-early-reviews-of-draft-ietf-schc-protocol-numbers-10-min} * Presenter: Pascal Thubert EV: It is probably about *early reviews* and not *IESG reviews* ;-) AP: oh, yes, thanks for the correction. PT presenting PT: This was moved from the INT Area to the SCHC WG, with little progress since then. We asked for early reviews. The draft requests the registration of an Internet Protocol Number, an Ethertype and a UDP port number. PT (p3): The reivew from EV stressed that the part on UDP port number is too light (TBD) and has to be expanded; IANA considerations have to comply with expectations; the supporting use case is too narrow. LT: There's another use case, i.e., IPsec. PT: Right, so we need to come up with more use cases. PT (p4): Showing exerpts from RFC 9542 as an example to start from for the Ethertype. In particular, you need to have a version and define the protocol version in the SCHC header. LT (on chat): :thumbsup: PT (p5): Showing exerpts from RFC 7042 as an example providing more input. In summary, the document needs a proper IANA section and IEEE section. The protocol must adhere to some conditions. PT (p6): Showing points from the review from Joe. Main point: we need a header. This is probably a misunderstanding to clarify. ... On a second thought, this needs more discussion. LT: We need a protocol number to indicate the SCHC content. That's why we need a stratum header now, to strip that value and get to the uncompressed protocol number. PT: That's right. PT (p6): A second point is challenging the use of a port number at the transport level to indicate the use of SCHC. That's unusual, as one typically negotiates. But that's not our intention, from my point of view this works and it's just unfashionable. We need to get to the details in his mail and discuss among us and with him. This particular case is about having uncompressed UDP vs UDP signaling SCHC. We also need to find a better justification to handle the presence of firewalls. PT (p7): Showing points from the review from Mirja. Main point: this can be done in the architecture document. The short answer is that we'd like this to happen quickly. Also, the architecture document is not supposed to be Standards Track, but we want the present document to be. From a time point of view, the IETF side can be accommodate by asking for an Early Allocation, but the same can't happen for the IEEE side. AP: I agree with your analysis and about keeping this topic in this document. PT: Too bad that EV has left; this comment also goes in a direction different from the one he was hoping for. PT (p7): Another point is about the use case being not clear enough when it comes to firewalls. AP: I find the use case of firewall traversal interesting. If the UDP port is well-known, the firewall can inspect the SCHC header and make an informed firewall decision. Maybe that can be an argument, but it requires to have a fixed SCHC header for that specific UDP port number. Yet, you need to keep a state. PT: You need a SCHC protocol asking the other party to start a SCHC instance with you. When you do so, you agree with the other party about the port number. AP: Then we can have a fix SCHC header that goes over a specific well-known UDP port number, and then one has to use that fixed, well-known SCHC header. PT: We need more discussion, with the architecture also as part of the justification. AP: We don't have to say everything in the architecture draft. PT: Right, and it doesn't have use cases, but we still need to position things in the context of the architecture. PT: Overall, this was very good input from the reviewers. ### \[16:40\] SCHC Architecture \[20 min\] {#1640-schc-architecture-20-min} * Presenter: authors AP: Skipped due to lack of time. We take it next time. PT: I won't be able to attend the next two interim meetings. ### \[17:00\] AOB \[ QS \] {#1700-aob---------------------------------------qs-} AP: We'll follow up with discussions on the mailing list. [1]: https://datatracker.ietf.org/wg/schc/about/ [2]: https://datatracker.ietf.org/wg/schc/ [3]: https://www.ietf.org/mailman/listinfo/schc [4]: https://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2024-9-3&sln=14-15 [5]: https://datatracker.ietf.org/doc/agenda-interim-2024-schc-12-schc-01/ [6]: https://datatracker.ietf.org/meeting/interim-2024-schc-12/session/schc [7]: https://meetings.conf.meetecho.com/interim/?group=c5d5c140-d61a-48b5-ab8d-f164cfd560c9 [8]: https://notes.ietf.org/notes-ietf-interim-2024-schc-12-schc [9]: https://datatracker.ietf.org/meeting/interim-2024-schc-12/sessions/schc.ics