Subject: [core] draft-ietf-core-block-08 - multicast

From: [email-masked]
Date: Tue, 17 Apr 2012 09:31:06 +0200

CoAP supports multicast but there is actually no text in core block about 
multicast.
Can we asssume that the stateless nature of core-block is enough to 
support multicast?
Do we need to put guidelines in core-block or group-comm ?

The first use case I see for multicast block is resource discovery on 
/.well-known/core.

Regards,
Matthieu

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 17 Apr 2012 14:16:35 +0000

In my view: if core-block intends to support it, that should at the very least be mentioned.
If core-block does not aim to support it, that should be shortly mentioned. (E.g. for the reason that there is not enough implementation experience yet with that)

A second use case is distributing firmware upgrades to a group of nodes by PUTting or POSTing blocks of data in multicast.

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday 17 April 2012 9:31
To: [email-masked]
Subject: [core] draft-ietf-core-block-08 - multicast

Regards,
Matthieu
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Apr 2012 17:08:03 +0200

> In my view: if core-block intends to support it, that should at the very least be mentioned.

Well, I'm not so sure.  Multicasting happens down at the message layer.
-block does not mention, say, DTLS either.
Is there something about multicast that requires special support in -block?
I'm not aware of it.

Grüße, Carsten

---

From: [email-masked]
Date: Wed, 18 Apr 2012 10:12:22 +0200

Hi Carsten

>Is there something about multicast that requires special support in 
-block?
I don't think so but is that clear enough to everybody such that we can 
just silently ignore the subject?

For example I don't expect core-block to be usable for full multicast 
blockwise transfer on /.well-known/core.
The client could just use block to first discover endpoints and make the 
responses to the multicast request fit a 802.15.4 frame. 
After that the client can follow with a sequence of unicast blockwise 
transfers with each discovered endpoint.
I admit that this -block usage could be described in group-comm or in a 
discovery draft rather than in -block.

Also we may want a stronger recommendation than coap-09 10.3.3. on -block 
need for multicast to mitigate amplification attacks.

My 2 cents,
Matthieu

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 18 Apr 2012 08:18:33 -0600

What about adding to the draft something like "this version of block was not designed for use with multicast and the block options SHOULD NOT be used in a message sent over multicast. Future specification MAY relax this requirement." And say something about what a node that receives a block option over multicast does with it. 

I can imagine using multicast block to do something like upgrade all the firmware on many devices at once.

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 18 Apr 2012 20:40:26 +0000

Maybe I could check a number of core-block + multicast use cases to see if special support is needed?

A first case: for a GET like in Fig 2 of section 3, but sent in multicast to a group of servers, some servers may send the last block earlier than others because of different resource sizes. These servers (with relatively small resource size) will get requests for block numbers that are too high / out of range.
Then the discussion "GETs beyond resource size" (http://www.ietf.org/mail-archive/web/core/current/msg02595.html ) becomes relevant except that the client really can't avoid sending such requests beyond resource size like it could in unicast.

Another case: a GET like in Fig 3 of section 3, but now multicast again to a group by the client. Suppose server S1 responds with Block option 2/0/1/64, while server S2 responds with 2/0/1/32. The draft states:
"The server SHOULD use the block size indicated in the request option
   or a smaller size, but the requester MUST take note of the actual
   block size used in the response it receives to its initial request
   and proceed to use it in subsequent requests."
Now S1 assumes that client MUST use size 64 in subsequent requests, while S2 assumes that client MUST use size 32 - an issue.
(Maybe the client could go for the lowest size returned over all servers in the group; but this needs changes in functionality)

Another point is that multicast uses NON messages, which presumably causes a different timing and interaction pattern than the existing examples in -block.
E.g. there's no retry of CON due to missing ACK on the one hand, but on the other hand a client has to retry the same NON to get the data blocks.
The current text raises a bit of the question "can I use NON in the first place?" and if so, any special timing/interaction patterns or is it simply the same as the pattern with CON/ACK (but then instead using NON/NON messages)?

There may be some more things raised by checking PUT/POST/DELETE cases or cases where some server(s) responds relatively late with block-size preferences.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday 18 April 2012 10:12
To: Carsten Bormann
Cc: [email-masked]; Dijk, Esko
Subject: Re: [core] draft-ietf-core-block-08 - multicast

Hi Carsten

My 2 cents,
Matthieu

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 19 Apr 2012 15:18:50 +0000

(Prev. email continued)

I checked some more cases of using block with multicast, based on the Examples in -block.
Conclusion: for me it's not clear how the current draft should be applied in multicast use cases. Various details are missing.
On the other hand, not all multicast+Block cases are useful - we should perhaps only check realistic use cases and make it work for those. (Nice input to the groupcomm draft?)

* Case multicast atomic PUT / Fig 7 & 9;
I think a server MUST be prepared to receive Block1 PUTs that use a same block number as sent before (e.g. block sequence 1 2 3 3 4 5 6 6 ... etc.)
Reason 1: a NON PUT was not received by all recipients known to the client, therefore client resends same NON PUT with a new MID. (for discussion: whether this is the right behavior?)
Reason 2: a NON PUT was truncated in a subset of recipients, returning 4.13, client retries with smaller block size to all recipients.

* Case multicast atomic POST with Block2 response / Fig 10;
- This case relies on the client sending empty ACKs with Block2. I assume such 'ACKs' are multicast. Is this possible? (Assuming NON is used for multicast and responses to multicast) Should it be an 'empty NON' or some sort of 'NON-ACK' (which behaves exactly like an ACK...)
  Or simply use CON/ACK anyway in this multicast case?
  The use of Block1/Block2 in an empty message seems not described in the draft.

- A server MUST be prepared to receive the 'ACKs' from the client for block numbers that the server did not even send.
  Reason: I assume these client 'ACKs' are multicast. One server S2 may prefer smaller Block2 SZX than server S1. Client adapts to smallest SZX (that of S2). E.g. S1 SZX=128, S2 SZX=64. S1 sends its first block 0 of 128 bytes, S2 sends its first block 0 of 64 bytes. Client 'ACKs' block 0 and indicates SZX=64 in Block2 option. Server S1 now sends block 2 (counted in the smaller size 64) and Server S2 sends block 1 (counted in block size 64 ). Client ACKs block 1 - which S1 did not send! Maybe a figure would be helpful here :)

- Finally, in Fig 10 the client seems to echo the M bit (in fact the whole Block2 option) that's sent by the server within the Block2 option. In a multicast case, that's not always possible since one server may send its last block while another one still has more blocks to go. So there need to be some rules defined how to handle this case.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Wednesday 18 April 2012 22:40
To: [email-masked]; Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] draft-ietf-core-block-08 - multicast

Esko

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Apr 2012 17:34:20 +0200

> What about adding to the draft something like "this version of block was not designed for use with multicast and the block options SHOULD NOT be used in a message sent over multicast. Future specif…

There is definitely one application that needs to work:

-- a multicast GET request is made to /.well-known/core (plus maybe some query parameters)
-- some of the (unicast!) responses contain Block2, some don't.

In this example, no Block option occurs in a multicast message, but multicast is used in the exchange.  A Block2 option could be used in the request to indicate a preferred response size, though.

I don't see a very convincing reason to continue using multicast in the followup blockwise GETs (block number 1 up).  I would have continued with unicast CON.

> I can imagine using multicast block to do something like upgrade all the firmware on many devices at once. 

Now this is Block1.
As Esko points out, this may need "manual" retransmissions.
Of course, an implementation might send multiple copies of the multicast NON with the same MID to accomplish that (saturation).

But all this sounds like material for the groupcomm draft, not for -block.
Block provides the mechanism that can be used in more or less interesting ways.
Trying to prescribe exactly the ways of using the mechanism we can come up with at the moment in the spec does not sound like a recipe for sound protocol evolution.  It also makes the spec appear way more complicated than it is.

Grüße, Carsten