Subject: [core] objectives of block-08 draft

From: "Stok, Peter van der" <[email-masked]>
Date: Wed, 25 Apr 2012 08:09:53 +0000

Dear Carsten and Zach,

Reading the block-08 draft I seem to understand 3 objectives of the proposed block protocol. I recommend to separate these in as many protocols.
The objectives of block as I understand them (correct me if wrong) are:

1)      Transfer of bulk of data when one datagram is not sufficient, like supported by tftp or, more efficiently from a packet number point of view, by tcp.

2)      Transferring a subset of blocks out of a sequence of blocks, like supported by NFS to transfer one specific disk block from the set of blocks constituting the file.

3)      Prevention of fragmentation at the link layer, thus increasing the reliability of the datagram transfer at network layer.

The problems I have with block-08 are:
As a consequence of combining these objectives, it is possible to define the block size. This possibility defeats objective 3, because fragmentation can occur.
Looking at the block protocol, I wonder if it is really better than what tftp accomplishes with respect to objective 1.

My suggestion is to leave objective 1 and adapt existing protocols like tftp or tcp, if the wish of bulk transport exists.
Objective 2 can be interesting, and I do see a use when a sensor accumulates history data, and a particular measurement out of the whole history is needed.
Objective 3 seems interesting given that many UDP based applications are optimized to send one UDP packet which unfortunately may exceed the payload size of a single IP packet.

Consequently, it seems reasonable to specify two protocols: a block transfer protocol (objective 2) and a fragmentation protocol (objective 3).
The possibly large blocks delivered by objective 2 protocol can be fragmented by objective 3 protocol.
For objective 3, one can ask whether this is single hop, or that it is an end-to-end protocol from fragmenting node to receiving or defragmenting node over multiple hops.

Greetings,

Peter

Peter van der Stok
phone +31 492 474673
mailto: [email-masked]

________________________________
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: Wed, 25 Apr 2012 18:11:49 +0200

Hi Peter,

the objective of the block options is to enable the transfer of payloads larger than can be comfortably sent in one datagram.

This is not exactly your objective 1, because CoAP is not meant to be a bulk data transfer protocol.  CoAP is efficient for bulk transfer in the sense that it does not tax network resources in an unneeded way, but it is not efficient in the sense of actually using all the network resources that may be available (like TCP would do).

"Comfortably" implies your objective 3, but is not identical with it.
Actually, objective 3 *cannot* be achieved until we have something like ALFI (http://tools.ietf.org/html/draft-bormann-intarea-alfi -- thanks for prompting me to finally write this one up).  But Block opens up the selection of datagram sizes at CoAP end-points sufficiently that they may be able to address most of this problem area.

Your objective 2 never was one.  It just turns out that the design of -block makes it trivial to achieve, so we decided to take it as well (rarely, but occasionally, simplicity and generality do have synergy).

> As a consequence of combining these objectives, it is possible to define the block size. This possibility defeats objective 3, because fragmentation can occur.

Obviously, adaptation layer fragmentation can occur, for the reasons that ALFI is addressing.  Right now there is no way to fix that.  (With ALFI, there would be.)

> Looking at the block protocol, I wonder if it is really better than what tftp accomplishes with respect to objective 1.

I have no idea what some people like about TFTP.  Its only redeeming feature appears to be that it has existed for a long time, and some of its considerable breakage has already been fixed.
But if it does solve your problem, you know where to find it.

> My suggestion is to leave objective 1 and adapt existing protocols like tftp or tcp, if the wish of bulk transport exists.

If bulk transport is a significant aspect of your application, you are better off with implementing TCP, which actually can fill all of the network resources available.
(We might even make CoAP available over TCP at some point in the future, it certainly has been designed to make that straightforward.)

Block has mainly been designed for CoAP applications that mostly need small payloads, but may need to ship larger objects e.g. during discovery and security setup.

Cullen has indicated that he has another interesting use-case where even the "small payloads" would benefit from -block; it will be interesting how to address this without ALFI, but I still think CoAP -block has all that's needed for that.  

Just don't ship the most recent episode of your favorite TV show over -block, please.

For now, I'll take this as an editorial comment to clarify the objectives of CoAP -block in the abstract.

Grüße, Carsten

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 26 Apr 2012 07:50:44 +0000

Hi Carsten,

Thanks for your extensive answer.
Glad to read that we agree more than I had inferred from the block-08 text.

If I understand correctly, block-08 specifies a way to transport 1-4 consecutive blocks of specifiable size reliably where the size of the blocks is independent of the units of transport over the link, but can be adapted to the unit of transport by the application.

> For now, I'll take this as an editorial comment to clarify the objectives of CoAP -block in the abstract.

Some text in block-08 that confused me:
- In the abstract several references to IP fragmentation are rather prominent.
- Introduction: bullet 2, reducing message size to minimize fragments
- Introduction: several references to link layer fragmentation
- Introduction: page 5, bullet 1, reference to link-layer
- section 2 page 6, bullet 3, reference to adaptation fragmentation
- section 2, use of coap datagram and coap message without knowing their relation and relation to payload size of UDP datagram.

Section 3 examples are rather protocol technical. The addition of an example at application level that explains the reason to use block for the presented use case(s) would be very helpful indeed.

>> As a consequence of combining these objectives, it is possible to define the block size. This possibility defeats objective 3, because fragmentation can occur.

I wanted to point out that when you want to avoid packet fragmentation, the maximum size of the blocks does not allow much negotiation (is fixed).
Giving the possibility of defining larger block sizes will lead to blocks which need to be fragmented which (in my understanding) you wanted to avoid in block-08 draft.

Thanks for the alfi draft; Rarely my suggestions lead to such fast reactions.
Explaining in block-08 better the relation between block option and the avoidance of fragmentation, also pointing out the variable payload size per packet could help understand the purpose of block much better.

Greetings,

peter

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Wednesday 25 April 2012 18:12
To: Stok, Peter van der
Cc: [email-masked]; Zach Shelby
Subject: Re: objectives of block-08 draft

Hi Peter,

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 26 Apr 2012 09:47:43 +0000

Confusion may be also caused by the difference between minimizing fragmentation and avoiding fragmentation. (Peter you mention avoiding.) One choice is to refer to "minimizing" rather than "avoiding" in -block?

Thus choosing a smaller block size will always (on average) reduce the probability of fragmentation, so ability to choose block size and negotiation to smaller block sizes really helps. (Without the CoAP end-point actually knowing whether fragmentation occurs.)

The following text in -block suggests "avoidance" a bit:

	"No hard-to-manage conversation state is created at the adaptation
      layer or IP layer for fragmentation."
rather -> "Minimal" or "less" hard-to-manage conversation state is created at the adaptation... ?

	"by the desire to avoid adaptation layer fragmentation (60-80 bytes
      for 6LoWPAN [RFC4919])"
-> "desire to minimize" ?

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stok, Peter van der
Sent: Thursday 26 April 2012 9:51
To: Carsten Bormann
Cc: [email-masked]
Subject: Re: [core] objectives of block-08 draft

Hi Carsten,

Greetings,

peter

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Wednesday 25 April 2012 18:12
To: Stok, Peter van der
Cc: [email-masked]; Zach Shelby
Subject: Re: objectives of block-08 draft

Hi Peter,

Grüße, Carsten

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Apr 2012 15:50:16 +0200

Peter,
Esko,

thanks, this is great input.  I now just have to find time to realize Klaus' and your really constructive input into a new version...

Peter: one comment: -block certainly is not *limited* to 1–4 exchanges, it is just optimized for it.
You can do a firmware upload (or maybe a state dump) using -block.
The one thing you cannot expect is to fill the network.

Grüße, Carsten