CoRE WG @ IETF90 (Toronto) Minutes draft version 0.1. Chairs: Andrew Mcgregor Carsten Bormann Thanks to the notetakers: Ludwig Seitz Ari Keränen Sandeep Kumar _______ _______ (please enter your name here if you were the fourth note taker) From these notes, compiled by Carsten Bormann. [Times/numbers in brackets indicate approximate position in the audio recordings **after a 0.75 stretch** (multiply by 4/3 for real time)] WEDNESDAY, July 23, 2014 1520-1650 Afternoon Session II Territories APP *** core Constrained RESTful Environments WG ** Intro, Status etc. (3 min) 15:20–15:23 Intro I Note-Well, Blue Sheets, Scribes, etc. Agenda bashing ** Special Slot: CoAP Congestion Control (Presenter: Carles Gomez) 15:23-15:43 draft-bormann-core-cocoa-02 (20 min) Objective: · Is this getting close to being useful? · Is this something the CoRE WG wants to work on? (or should it be done elsewhere?) · If yes: Do we want to adopt this? When? Goal: Simple mechanism for advanced congestion control, based on RTT measurements Question, Lars Eggert: Please explain RTO estimator, weak and strong part Carsten: history of that: because of ambiguity of whether response is for original transmission or for a retransmission: strong indicator for RTT on CONs without re-transmissions, weak with re-transmissions Lars: Does this actually help you, or just add complexity? Richard Scheffenegger: Unnecessarily complex for constrained devices? Carles goes through the updates for 02 draft. Running code: Implemented on Californium. Carles presents measurement results for evaluation of CoCoA. [11:05] Lars Eggert: A bit odd to see a mechanism that should prevent overload evaluated on throughput. Need to see data on network load caused by CoCoA. Carsten: the paper actually has more results on re-transmission etc, seems to look good [12:20] Michael Richardson: Did you do measurements with Block mode Carles: not yet Carles presents impact of traffic burst. [14:30] Lars Eggert: (slide 16) asks for explanation of the graph Carles: total traffic what is the capacity of the path? Carles: 10-15 kbit/s Lars: Would be interesting to see if curve continues going down if you increase x-axis (number of clients), because that is what you don't want to see. [15:30] Zach Shelby: Useful. Comes up in lots of Smart Cities applications. But scale up: need to increase the number of nodes to ~ 1000. Look at interaction with DTLS. Also GRPS is going out of fashion, should try with 3G. [16:45] Jörg Ott: Question on stability: How many different topologies did you try? Chains, grids, clusters, ... Carles: Simulation was considering chain, dumbbell, grid topologies. Testbed is just a mesh. So we do have some coverage. Re stability: We tried to fine-tune the mechanism based on earlier observations. [17:40] Robby Simpson: Should there be a requirement to be TCP friendly? Carles: Yes, I believe it is. We are not doing anything that would go beyond the guidelines in RFC 5405. Lars Eggert: TCP friendly not so interesting. 1 -- Need to prioritize metrics differently. Is the mechanism safe? Can it protect the network from being overloaded over long period of time? Only after that other metrics are interesting. Safety is the key. 2 -- Do you have measurements to simply calculate the RTO without weak and strong? Dropped packets do imply congestion. Carles: Done just a few simulations, testing only the strong estimator. Lars: Also test only the weak estimator! [19:55] Andrew McGregor (no hat): For CoAP default congestion control is very conservative. Be careful with extrapolating from small-mesh measurements to a larger number of hops and sizes of mesh networks. WRT TCP friendliness: This needs to not die in the face of TCP. [20:40] Richard Scheffenegger: What Lars said. Also, would be interested in evolution of RTO estimates over time. Unsuccessful, or spurious re-transmissions? Number of re-transmissions going up? [21:10] Zach Shelby: Wrote with Matthias a paper on why CoAP is good for server scalability. Make sure does this does not make it worse. [21:40] Carsten Bormann (no hat): Answer to what this is supposed to achieve: Don't implement this if you have a class-1 system. This is meant for systems with more power than class 1 and can handle three additional state variables etc. in order to get a bit better performance (no miracles, though). Earlier versions became unstable in some cases, we already have some indication that the strong/weak estimator works better. [23:05] Richard Scheffenegger: Is it more important to protect the network or is it ok to be a bit more aggressive in order to get a better response time? Carsten Bormann: TCP has an easier job because it has more packets in flight. We are going to see more variability, running lock-step. Prime directive: Don't melt the network, but within that try to get better predictability. [24:50] Robby Simpson: CoAP on 15.4 networks: packet loss not an indication of congestion, just wireless nature of the network. Carles: Weak estimator is there to handle very lossy networks (still gets information from them). [26:00] Zach Shelby: Problems with networks with very different delays. Longer with many hops, real issues in cellular, very slow! Needed to hard-code longer timeouts. Would this help with automatic timeout adjustments? Carles: Yes! [26:50] Ari Keränen: Implementation question: Implementation on constrained device? What is the footprint and implementation effort? Carles: Don't have numbers here, but yes, was implemented on Class 1. Ari Keränen: how about using only some of the tricks but getting most of the benefits? Would that be possible? Carles: seems that the methods are very complimentary, but would need to look further. [28:05] Lars Eggert: Need more time for more evaluation of this, maybe in a smaller group. Talk to transport ADs... Carles: Please experiment with Californium with CoCoA, implement this in other places and share results. [29:05] Andrew (w. hat): Who thinks this is useful? 12 hands yes, zero hands no Andrew: Should this be done in this WG: 4 yes, 1 (Pascal) elsewhere (Andrew asks why:) Pascal Thubert: Should at least be presented at transport area. Carsten (w. hat): Idea: first get something that is good enough to recommend it for implementation and experimentation, then present on a larger scale. Robby Simpson: (elsewhere): Should be a lot of competence in Transport. ECN could be a good idea. Not all losses are congestion related. Lars Eggert: ECN is interesting, but how do you deal with it here? Transport people have expertise to evaluate this, but this is non-standard, different network, many of our techniques don't apply. 'Good enough' wrong metric, super-safe first! [32:00] Richard Scheffenegger: Is this the one and only mechanism to do this (RTO calc)? Other mechanisms available with different properties, some may be more appropriate. [32:50] Pascal Thubert: ECN can be a fantastic tool. When treating a 6LoWPAN packet we don't want to drop this just to indicate congestion. [33:30] Robby Simpson: Loss is not the only metric. Could look at TCP vegas? [33:50] Lars Eggert: Has anyone looked at setting ECN bits when there is a radio link and the radio quality gets bad? Andrew: 802.11 could couple rate control Lars: Ericsson might have developed more creative uses of ECN, might check with them [34:35] Carsten: No, this is not meant to be the only and final method. Work will continue. No need to *standardize* algorithms since this is unilateral (client side only). [35:25] Andrew (w. hat): Do we want to adopt this? Pascal Thubert: Standards track vs. experimental? AD interrupt (Barry): Adopting is necessarily as is, but just as a starting point, the working group will then work on it, also maybe change from experimental to standards track. Lars Eggert: CoRE should definitely work on this area. (Is this a good starting point?) That's another question. Probably even OK as a starting point, but don't try to publish it quickly. Take enough time for a very very thorough analysis. Might get more eyeballs as a WG item. Barry: Lars, would you work with the authors to produce a better starting point before the WG adopts it? Lars: not going to help; I can't run experiments because I don't have IoT testbeds. We don't have an IoT research group. Somebody needs to do PhD on this. Interesting first results. It's a good starting point but gonna take a few years. [38:20] Zach Shelby: Suggestion: question "is this a good starting point and we add a charter item" Andrew (w. hat): Should we add a charter item for this? 8 yes 0 no. -> Document remains as individual doc, but will work to add the charter item for this work. Carsten thanks the transport people who came in. [39:40] ** Intro, Status etc. (7 min) 15:43–15:50 Intro II WG Status: - Published: RFC 7252 (was draft-ietf-core-coap-18) - @IESG (AD evaluation): draft-ietf-core-observe-14, draft-ietf-core-groupcomm-20 - Last Call completed: draft-ietf-core-block-15 - Milestones Back to Introduction in the agenda. Document submission to IESG Barry: curious of security bootstrapping item; is this the one was parked and move to ACE? Carsten: bootstrapping is out of scope for ACE, but they are addressing a good part of this problem otherwise. Barry: -> when re-charter, can drop that item and be done with it Pascal Thubert: Part of this work in 6TISCH Carsten: I don't think 6TISCH is chartered for this work, either. [41:25] Samita: Will ACE work on Network access control? Carsten: No. Carsten: RFC 7252 published, and I have have resolved to never have a normative reference to a security document that isn't done yet. Zach Shelby: Advertisement on RFC7252: look at http://coap.technology website, contact us if something is missing. [44:05] Barry: Observe going to last call on Friday, Groupcomm ASAIC (As Soon As I Can) Core mailing list is on the notify chain, don't jump on IESG, but do engage. Carsten: Discuss in WG first, please. (more WG status report) [45:40] Agenda bashing: No comments [46:15] ** Block 2nd WGLC 15:50-16:00 draft-ietf-core-block-15 (10 min) (hopefully -16 by then) -- 2nd WGLC completed 2014-07-18 Objective: · sanity check before publication request Block-15 Editorial update, -14 plugtested in London, worked well Carsten: I missed on older ticket on content-format mismatch. Also some other editorial changes. So there will be a -16? Carsten: Sanity check? Andrew: Would people object to submit this to IESG? (None) [48:50] ** WG docs: HTTP-CoAP Mapping (Presenter: Salvatore Loreto) · (Akbar is the backup) 16:00–16:15 HTTP mapping (SL) draft-ietf-core-http-mapping-04 (15 min) (Background reading: draft-castellani-core-advanced-http-mapping-04 (0 min)) Objective of presentation: · Review two open tickets (#365, #366) · We expect to be able to close #365, and can give status update on #366 Presenter: Akbar Rahman changes from 03 to 04; Media type conversion Draft focuses on Reverse Cross-Protocol Proxy [51] [56:20] Yusuke Doi: Have use cases in EXI, what is the role of this document? Gives best practice? Need extension for specific binary formats, e.g. for usage in some industry standard such as SE 2.0 Could provide input on this? Akbar: Is a guideline for a mapping implementation. Motivation for this: reverse-proxy not well defined in CoAP. Yusuke: Have use case which uses special media type. Would be good if document specified support for this. [59:38] Zach Shelby (on Ticket #366): Why just blindly expose .well-known/core to reverse-proxy? Reverse-Proxy should act like an origin server, so it should build a .well-known/core for itself mapping all its origin servers. [61:00] Dave Robin: Payloads of CoAP messages might also contain links in CoAP domain, translation difficult for proxy if it doesn't know they are there, they might be signed, etc. [62:25] Zach Shelby: Tricky problem, don't do that! Don't worry yet about links behind links (behind links). If you are careful, provide recommendations. If links are relative this could be done. Bindings tend to use full URIs Dave: How to map full CoAP URIs to HTTP? Zach Shelby: Some parts might work, some not. Might be a recommendation on what not to design. Carsten: not CoAP-specific problem, also HTTP-cross domain proxy has the same issues, maybe we can tap on the HTTP people how to handle this? [64:10] Michael Koster: Question about content types, if you get e.g., ct=50 do you plan to transform this to application/json? Akbar: I'll send these questions out on the list. [65:00] ** Status checks (chairs, 5 min) 16:30–16:35 comi, alt trans (chairs) comi draft-vanderstok-core-comi-04 alt trans draft-bormann-core-coap-tcp-01 draft-silverajan-core-coap-alternative-transports-06 draft-savolainen-core-coap-websockets-02 Objective: - Are we on track with this work? - (comi:) how do we share this with ops community - (alt transports): which ones are we ready to adopt? Carsten: Three minutes left; diverting agenda to the comi draft, draft-vanderstok-core-comi-04 Is this fully cooked already? It's a data format, an application later protocol, a management thing. How do handle this? Maybe convince the OPS people that it would be good to run this here. Carsten: Do we want to move forward with this now or does it need more work on the protocol level? [66:30] Peter Van Der Stock: Comi is evolving, trying to make it more small-devices directed; less SMI vs. NETCONF, more about contents sent to small devices. Juergen Schoenwaelder: Agree there is a problem here. People need to get together and make a plan. Currently spread out in various places: Comi here; 6Tisch: CoAP, CBOR, YANG; Restconf in OPS;... Carsten: who are the interested people in this room: Kepeng Li, Carsten Bormann, Juergen Schoenwaelder, Peter Van Der Stock [68:00] end of Wednesday meeting THURSDAY, July 24, 2014 1730-1830 Afternoon Session III Salon B APP *** core Constrained RESTful Environments WG [02:45] ** Intro (3 min) 17:30-17:33 Carsten: Compressing Agenda (running at 150 % speed) ** WG docs: Links-JSON (Chairs) 16:15–16:20 Links-JSON (chairs) draft-ietf-core-links-json-02 (5 min) -- we tabled this waiting for implementation experience. Objective: - Are we there yet? (No implementers of the draft in the room, so mostly deferring) Carsten: Links-json is an array which makes updating with json-merge-patch difficult; should we be using a map (JSON "object"), indexed by href? Zach: triple: [context URI, target URI, and relation], are all three needed to make links the same Carsten: We may have to look for something better than merge-patch, then. Take it to the list. [05:15] ** WG docs: Core-Interfaces (chairs) 16:20–16:25 Core-Interfaces (chairs) draft-ietf-core-interfaces-01 (5 min) -- this draft is expired -- reason? Objective: - Is this work that is continuing? - If yes, how? Carsten: what next steps Zach: apologies for letting this (and the next one) expire. This draft is pretty much done. 1) reference to observe parameters; 2) LWM2M references need to be extended somewhat. Needs eyeballs; to resubmit now, then a larger editing round. Carsten: -> some editing, call for review, and go for WGLC [07:20] ** not yet WG docs: Resource Directory (chairs) 16:25–16:30 Resource Directory (chairs) draft-ietf-core-resource-directory-01 (5 min) -- this draft is expired -- reason? -- this draft is a WG document but outside the charter Objective: - Is this work that is continuing? - If yes, how? Zach: also expired by mistake. I started receiving hate mail the night this expired... This is really being used. Before resubmit need some consensus on new technical changes. Five open tickets in progress. -- use case addition -- dns-sd mapping (with help from Kerry Lynn) -- DDOS security considerations (lookup responses are large), text in the ticket -- need examples section more complex than the existing in-line examples -- the technical one: New registration update interface. Update as a PUT, without payload (LWM2M actually allows payload to add resources!). Change PUT to POST. Added link payload to add links. Exact match (see triple above) replaces current link. No method for removing links. [11:05] Matt Gillmore: For my use case PUT was good. POST will not hit the correct resource. Zach: In the initial registration, you have to do a POST. The update is a non-creating POST, just a refresh (a command). Carsten: Collection POST, vs.... Michael Koster: first post creates handle, second adds links Zach: does not seem to be the problem. Kerry Lynn: Semantics? Can you change an existing link Zach: yes, with this new update; but need pretty strong language not to do it always Zach: Will give a week, if no issues with the change, will post new version. One more editing round and expert reviews (one from OMA and one inside IETF). [15:09] Kepeng Li: difference between this and OMA work? Zach: it's the same; spec in practice was duplicated because OMA can't reference Internet-Drafts. OMA 1.1 reference will be updated when this becomes RFC. Other Updates needed for SenML, CBOR, ... IETF is a bit more glacial... Support PUT and POST for backwards compatibility? This is the time to fix it now. [17:20] ** Status checks (chairs, 5 min) 16:30–16:35 comi, alt trans (chairs) comi draft-vanderstok-core-comi-04 alt trans draft-bormann-core-coap-tcp-01 draft-silverajan-core-coap-alternative-transports-06 draft-savolainen-core-coap-websockets-02 Objective: - Are we on track with this work? - (comi:) how do we share this with ops community - (alt transports): which ones are we ready to adopt? Carsten: Two items floating; 1) Comi discussed yesterday: to have hallway meeting tomorrow (Fri) 9 to 12 Wide group of people to meet; carry back plan if one comes up [18:20] 2) Alternative transport drafts: over websockets, over TCP seem to be stable; URI issues seem to be getting better; over SMS is underspecified right now in LWM2M and needs to be further worked out. [21:20] Andrew: any objections to adopting over tcp and over websockets as charter items? Kepeng: Not sure for websockets, overload for constrained devices Andrew: Websockets themselves are still stabilizing. Zach: -- Supportive of TCP and URI. -- SMS needs to be worked out better. -- TCP should have *one* way defined. -- Websockets is a concern; I'd want to see people really using it. (Websockets are being abused in IoT as a way to hide proprietary protocols.) Andrew: So, be careful about charter text for Websockets. [23:55] Akbar: support alt transports but jumping too soon for which particular ones. [24:50] Carsten: the listed ones are being used in a proprietary way or underspecified; we are no longer in a stage where we need to do a survey what people need. Akbar: TCP and SMS OK Zach: ... Coap over Legos... AD: charter item should be for alt-transport, and then decide in the WG decide which particular transport. Ari: if this is accepted as charter item, would it mean some other would not be? Carsten: We are ticking off charter items at a reasonable pace now, I'm not as worried about charter items now... Andrew: no, all candidates are fairly small so can be accepted or not independently of each other -> Charter to be updated for alt-transports [28:00] ** Avoiding responses to POST and PUT (Presenter: Abhijan Bhattacharyya) 16:35–16:45 No-Response (AB) draft-tcs-coap-no-response-option-06 Objectives: · With the modifications in the most recent draft, is the proposed option now the right way to solve the problem(s)? Objective: · Discuss updates on No-Response draft (mainly updates related to Token handling) · Are we there yet? [28:45] Abhijan: Discussed this previously. One technical comment remaining: how to handle token reuse. No-response + NON, client has to decide to retire a token and reuse it. Server may send a response (even with no-response) but then to which request the response should be matched issue. TOKEN_REUSE_TIME similar to groupcomm to solve the issue. [32:40] Kepeng Li: Patience... cf. my draft which is up later. Carsten: show of hands who think they want this feature in their implementations? (Not very many implementers in Toronto!) One hand, some skeptical faces. Andrew: Insufficient energy in the room. Will take to the list. [35:00] ** CoAP-MQ 17:33-17:53 coapmq (Michael Koster) draft-koster-core-coapmq-00 Objectives: · Can CoAP-MQ cover the use case for sleepy node support? · Can CoAP-MQ cover the use case for mirror server? · Should the WG take up this work on standards track? Michael Koster: New draft: CoAP-MQ Enabling publish-subscribe communications, cover existing work on "mirror server"; sleepy node support, and communication for unreachable nodes. Topics match to resource paths, Broker concept; use observe and/or PUT Open issue: registering endpoints and topics separately; context of a topic may be something else but an endpoint. [41:20] Zach Shelby: the default link relation is host; may not be the right one here, as the topic is not hosted at the endpoint. [43:25] Barry Leiba: what I'm missing is who needs this? Why do we have this instead of just observe? Michael: sleepy nodes & mirror server use cases; incorporating pub-sub also covers use case of making the protocol easily bound to other pub-sub systems [44:05] Kepeng Li: you cache in MQ node; the data is not fresh(?). Michael: LWM2M queue binding; when endpoint updates registration, the middleware/platform part sends what is queued Kepeng: Not sure how much helps sleepy nodes. [45:35] Zach: I think point here is that this is functionality for proxy. Can use queue mode for many things. Problem with mirror server: it was never REST; it was kind of pub-sub. This is a simple way to do this. Also some people really like pub-sub and we don't want to alienate them. Works with same protocol and same security transport. [46:40] Tim Carey: Don't think we're solving sleepy node problem. From web app perspective needs to be agnostic of sleepiness of the node. Need to be a pub-sub application. Would like to have same way for sleepy and non-sleepy nodes. These mechanisms are using good things. Some apps want to work in pub-sub model. There is value in having this kind of pattern, but maybe doesn't solve the sleepy nodes problem. [48:00] Michael: web client can still do REST GETs and PUTs. Tim: REST is more than GET and PUT. [48:30] Zach: nothing prevents using different types of resources. This solves sleepy node problem as well as anything else [49:15] Dave Robin: this doesn't solve sleepy actuator problem. Michael: this also includes LWM2M queue mode, not taking away anything; will allow actuator to wake up and receive commands Dave: OK [50:10] Chair: seems interesting work, needs more work Sorry for Kepeng's items below. [50:20] .... out of time .... ** other continuing work 17:53-18:15 node-id (Kepeng Li) draft-hong-core-coap-endpoint-unit-id-00 draft-kleine-core-coap-endpoint-id-00 draft-li-core-coap-node-id-option-01 patience (Kepeng Li) draft-li-core-coap-patience-option-04 ** Flextime 18:15–18:30 Flextime · Open Mike