Subject: Re: [core] Lenght shim

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Aug 2015 22:29:33 +0200

Hi Simon,

I discussed this with my co-workers and we prefer option A. We like it
because of the simpler nature because option B really changes the
semantic of the CoAP header.

Ciao
Hannes

On 07/27/2015 04:47 PM, Simon Lemay wrote:
> 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 conta
ining 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
> 
> 
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: 고석갑 <[email-masked]>
Date: Thu, 13 Aug 2015 02:49:35 +0000

Hello. 

I prefer option A, too.
TO cover Option A, I think we can add the similar method of Option format in CoAP to extend Length Shim field.

0~65532 Length shim, no extended Length
65533 4byte extended Length field + 65533
65534 8byte extended Length field + 4295032829 (2^32+65533)
65535 reserved

- Softgear Ko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, August 13, 2015 5:30 AM
To: Simon Lemay <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] Lenght shim

Hi Simon,

I discussed this with my co-workers and we prefer option A. We like it because of the simpler nature because option B really changes the semantic of the CoAP header.

Ciao
Hannes

On 07/27/2015 04:47 PM, Simon Lemay wrote:
> 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)
> 
> ??????????????????-
> -can be remove is faming is not needed -application layer 
> fragmentation helps with multiplexing request
> 
> 
> 
> Cons
> ??????????????????-
>  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 conta

---

From: "weigengyu" <[email-masked]>
Date: Thu, 20 Aug 2015 18:25:13 +0800

Hi all,

I have a question on this and a suggestion.

If the case of CoAP is only over TCP, option A is OK.

But if the usage senario is that there are three nodes;
C is a CoAP client, S is a CoAP server, and I is an intermediary.
        CoAP Client -------------- Intermediary --------------- CoAP Server
                C                                   I 
S

Suppose, transport layer protocol between C and I is TCP and that beween I 
and S is UDP.
If all the CoAP messages between C and I are NON,
which message between I and S shoule be CON?

If the intermediary works as a proxy/application gateway,
it can make a meassage, but it has not any knowledge about the message type 
form the received meassage.

It is clear that the way of opion A is to add a prefix of CoAP message,
this suggestion is to add two more attributes in the prefix.

E 2bits and TMB 2bits.
E is effective, 1 is effective and 0 is not.
TMB is type mask bit, it is use to overload T that the type attribute in 
CoAP message when E is effective.
So, the suggesting message format is the prefix + message format of RFC7252.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ML Message Length           |  E |TMB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And I do not think that the message ID of RFC7252 needs omitting.
This is because when running CoAP over TCP, the networks mostly are 
less-constraint or not constrainted networks.
2Byte (16bits) message ID would not be concerned as overheads.
And it brings conveniece for intermediary to do message process.

The CoAP client can work as RFC7252 defined.
Before delivering to the transport layer,
if the underneath layer is TCP, a reliable transport facility,
it add the prefix, ML, E=1 and TMB=01;

For the Intermediary, if the incoming message is received over TCP, a 
reliable transport facility,
do precessing by the prefix functions. As E=1 and TMB=01, it means NON.

If the inermediary is an application proxy or application gateway, for 
forwarding the message it could delete the prefix, then deliver over UDP.

For the server in the constrained networks, do works as RFC7252 defined.

Regrads,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

-----原始邮件----- 
From: 고석갑
Sent: Thursday, August 13, 2015 10:49 AM
To: Hannes Tschofenig ; Simon Lemay ; [email-masked] WG
Subject: Re: [core] Lenght shim

Hello.

I prefer option A, too.
TO cover Option A, I think we can add the similar method of Option format in 
CoAP to extend Length Shim field.

- Softgear Ko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, August 13, 2015 5:30 AM
To: Simon Lemay <[email-masked]>; [email-masked] WG <[email-masked]>
Subject: Re: [core] Lenght shim

Hi Simon,

I discussed this with my co-workers and we prefer option A. We like it 
because of the simpler nature because option B really changes the semantic 
of the CoAP header.

Ciao
Hannes

On 07/27/2015 04:47 PM, Simon Lemay wrote:
> 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
> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Aug 2015 14:50:54 +0200

Hi Gengyu,

thanks for your response and the question you raised. Here is my
impression about what happens in this case:

On 08/20/2015 12:25 PM, weigengyu wrote:
>                C                                   I S
> Suppose, transport layer protocol between C and I is TCP and that beween
> I and S is UDP.

The CoAP client would use TCP with the gateway and the data transfer
would be transmitted reliably due to the nature of TCP (regardless of
what CoAP says).

Then, when the data is at the gateway a new CoAP over UDP message would
be created and sent to the CoAP server. For the CoAP client the
interaction with the CoAP server isn't visible since the entire
communication terminates at the gateway. As such, the gateway needs to
have some application level knowledge to know whether the application
demands reliable transport or not.

I see two possible approaches:

1) The gateway assumes that the use of TCP between the client and itself
is an indication that the client wants reliable data transfer and
therefore would replicate this functionality also in the exchange of
data between the gateway and the server. It would therefore use CON.

2) The gateway re-uses whatever is conveyed in the CoAP message.  For
example, if the CoAP message from the client is a CON then it would be a
CON also on the other side.

Do you believe the draft should recommend one way or should this be left
open for deployments to choose?

Ciao
Hannes