Subject: [core] Lenght shim

From: Simon Lemay <[email-masked]>
Date: Mon, 27 Jul 2015 07:47:55 -0700

Hi,

So after the meeting on Friday, a few of up stayed to talk about the different alternatives on how to represent the length information in CoAP over TCP (reliable transport)

2 option came out of the meeting.

——————————————————-
Option A
2 byte shim with new Blocking option for bigger application layer fragmentation

This would consists of 2 bytes (16 bits) giving a max length of 64kb.  we would also add a new size option in the block size for FFFF (minus the header).

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Length Shim  |Ver| T |  TKL  |      Code     |   Token (TKL
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   bytes) ...  |  Options (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|    Payload (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The new blocksize needs to be a clean fraction of the 1024byte block.  This is needed for proxying blocksize across different transport layer.

Pros:
-easy to manage
-can be remove is faming is not needed
-application layer fragmentation helps with multiplexing request

Cons
-Does not support larger than 16 bits.
-could not do streaming

——————————————————-
Option B
Option like split length with a no length option for reliable transport that already have a framing

 The initial byte of the frame contains two nibbles, in a similar way to the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble is used to indicate the length of the options (including any option delimiter), and the payload (if any); it does not include the Code byte or the Token bytes. The first nibble is interpreted as a 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the options/payload, in bytes. The other three values have a special meaning: 13: An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. 14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. 15: A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805.  16: no framing. The second nibble of the initial byte indicates the token length. Example: 01 43 7f is a frame just containing a 2.03 code with the token 7f.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Len  |  TKL  | Len+ bytes... |      Code     | TKL bytes ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Options (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|    Payload (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Pros:
-supports larger payload
-flexible (dynamic payload size)
-removed the Message Type field

Cons:
-Large message might be difficult to parse or flush for more constraint node.
-cannot be removed if underlining implementation does not need framing

Let me know what you guys think, any pro or cons missing and what we should process to

Cheers

Simon

---

From: Simon Lemay <[email-masked]>
Date: Mon, 27 Jul 2015 08:12:29 -0700

Made a few correction
(Thank you Klaus for pointing them out :) )

Cheers

Simon

> On Jul 27, 2015, at 7:47 AM, Simon Lemay <[email-masked]> wrote:
> 
> Hi,
> 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Message Length         |Ver| T |  TKL  |      Code     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Token (if any, TKL bytes) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options (if any) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1 1 1 1 1 1|    Payload (if any) ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> The initial byte of the frame contains two nibbles, in a similar way to the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble is used to indicate the length of the options (including any option delimiter), and the payload (if any); it does not include the Code byte or the Token bytes. The first nibble is interpreted as a 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the options/payload, in bytes. The other three values have a special meaning: 13: An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. 14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. 15: A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805. The second nibble of the initial byte indicates the token length. Example: 01 43 7f is a frame just containing a 2.03 code with the token 7f.
> 
> 
> 
>  0                   1                   2                   3
(Need to specify an option for no framing, 12?)

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Jul 2015 17:34:15 +0200

Hi Simon,

thanks for writing this up.

In Option A, the length shim can simply be elided for transports that
provide framing.  There is no T, just two bits that we want to set to
some predefined value (say, 01).  (You already sent a corrected picture
for the 16-bit message length.)

In Option B, there is not really a need to indicate a length for
transports that provide framing.  I'd say, for this case the 4-bit
length field is always set to 0.  Maybe remove "with a no length option
for reliable transport that already have a framing" from the short
description as this is a detail.

I don't understand the cons listed for B, because B still is as short A
if the Option A length shim could be elided, and shorter in many other
cases.  The other con is really about sending large messages in the
first place, not about option B!

It's 64 KiB - 1 B, not 64 kb...
There needs to be a specification of what is included in the length.
(For option A, this would likely be everything after the length shim,
but we also could use a small offset, e.g., length=0 could indicate a
two-byte message, length=1, 3-byte, etc.)

A new szx=7 to enable larger block sizes could simply indicate that the
total body is to assembled serially from the payloads provided in
sequence; this only really makes sense when keeping a sequence of blocks
within an instance of a sequence-preserving transport.  But I would
write this up separately, not in this draft.  (And please expand on "The
new blocksize needs to be a clean fraction of the 1024byte block.  This
is needed for proxying blocksize across different transport layer.".)

Grüße, Carsten

Simon Lemay wrote:
>  The initial byte of the frame contains two nibbles, in a similar way to the CoAP option encoding (Section 3.1 of [RFC7252]). The first nibble is used to indicate the length of the options (including any option delimiter), and the payload (if any); it does not include the Code byte or the Token bytes. The first nibble is interpreted as a 4-bit unsigned integer. A value between 0 and 12 directly indicates the length of the options/payload, in bytes. The other three values have a special meaning: 13: An 8-bit unsigned integer follows the initial byte and indicates the length of options/payload minus 13. 14: A 16-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 269. 15: A 32-bit unsigned integer in network byte order follows the initial byte and indicates the length of options/payload minus 65805.  16: no framing. The second nibble of the initial byte indicates the token length. Example: 01 43 7f is a frame j
ust containing a 2.03 code with the token 7f.
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core