DOTS session IETF 111

29 July 2021

WG Drafts Status

current drafts’ status is shown in the slides

DOTS Signal Channel Call Home

On the agenda for 12 August IESG telechat
ADs who have not reviewed the draft will review and may have detailed comments
other ADs may only review diff from their previous version.
Finally moving forward again, and no known issues predicted

DOTS Multihoming

relatively minor changes only since -05
text believed stable
requesting WGLC
Valery: hopefully issuing WGLC will get more reviews, as not much discussion yet
Jon: there isn’t too much there to review, just guidance with a set of examples, but yes, this may trigger some more reviews

Signal Channel Configuration Atttributes for Robust Block Transmission

background: telemetry data too large to fit in single IP datagram, but DOTS signal chanel needs to use NON messages due to congestion
libcoap supports Q-block now, so we can have running code Q-block introduces new congestion-control-like parameters, which we now need to convey in DOTS session configuration
Augment the YANG module from 8782bis to do so request WG adoption
Kaname: with the new options, we clearly also need a way to negotiate and configure it, so I support this draft

Telemetry Use Cases

Addressed all comments from WG
Requesting WGLC
Valery: not much discussino of this draft on the list, but issuing WGLC might inspire more people to give comments. We can issue WGLC soon, approximately the same time as DOTS multihoming.

DOTS Q-Block interop report

Target draft draft-ietf-core-new-block-14 (latest)
different DOTS implementations, both using modified libcoap from Jon
Successful communication (recovering whole body of message) in the face of packet loss
No problem with core q-block over the internet (no loss)
Use iptables to introduce asymmetric random packet loss for packets from server to client
Could recover entire body even up to 10% packet loss
Found a few libcoap bugs (now fixed):

• What (CoAP) method to use for requesting missing response blocks - e.g. using PUT triggered a full response, but should use PUT to request missing response blocks.
• An initial GET for the entire message could be misunderstood as request for just the missing blocks of a previous response. Clarified that GET (NUM==0, Mbit=1) should be treated only as a request for the entire body.
  Valery: you used the same libcoap q-block implementation, so it’s not really independent
  Kaname: yes, but the applications on CoAP (DOTS communication) are independent implementations
  Jon: libcoap evolved with the q-block document, which does much of the work. The implementations we tested share a common libcoap layer that handles most of the Q-Block functionality, recovery, etc., but the DOTS layer is independent and the DOTS layer has to invoke Q-Block as appropriate.
  Valery: I will issue adoption call soon
  Jon: when the CORE RFC is issued, we will add text to the telemetry document to encourage its use

Charter update?

Valery: The charter has a lot of introduction and only the last couple paragraphs talk about what to do. I already edited the milestones, which are now waiting for AD approval. I don’t have new text for the charter handy, but I want to know if people think it’s a good idea to more precisely describe what we’re working on.
Ben: we already published 8782/8783, so we may not need to spend so many words talking about the core technology. We could make an update to be closer to what we’re working on. We could declare success and close the WG as well.
Valery: I will work with Frank to prepare some candidate text.
Ben: sounds good

Open Mic

[no comments]