Subject: Re: [core] Last Call: <draft-ietf-core-coap-14.txt> (Constrained Application Protocol (CoAP)) to Proposed Standard

From: Shoichi Sakane <[email-masked]>
Date: Tue, 19 Mar 2013 09:55:37 +0900

> 4.6.  Message Size
>
>   A CoAP message, appropriately encapsulated, SHOULD fit within a
>   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
>   one UDP payload) obviously MUST fit within a single IP datagram.  If
>   the Path MTU is not known for a destination, an IP MTU of 1280 bytes
>   SHOULD be assumed; if nothing is known about the size of the headers,
>   good upper bounds are 1152 bytes for the message size and 1024 bytes
>   for the payload size.

>      this may motivate
>      implementations to be frugal in their packet sizes and to move to
>      block-wise transfers [I-D.ietf-core-block] when approaching three-
>      digit message sizes.

This draft says a coap message must fit within a single IP datagram.
on the other hand, however, to avoid fragmentation, this draft may
suggest to use the block-wise transfer, which is defined by another
draft.

If the payload size is more than the minimum MTU, the block-wise transfer
works.  If the total length of the options is bigger, the mechanism
doesn't work.  And, the length of URI is likely to be bigger than the MTU.

Do you assume a use case in which the total length of options is going
to be greater than the MTU ?

One possible solution is that a fragment option is defined and is placed
at the first than other options.  And, However, the option number has a
semantic, and the order of the options is settled.  There is no room for
the block options to be placed at the first.

Shoichi

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Mar 2013 00:34:58 +0100

Hi Shoichi,

On Mar 19, 2013, at 01:55, Shoichi Sakane <[email-masked]> wrote:

> And, the length of URI is likely to be bigger than the MTU.
> 

CoAP has been designed for constrained devices, and networks built out of these devices (constrained node networks, draft-ietf-lwig-terminology).

In REST, servers can structure their URIs in a way that is appropriate for the intended use.
We would expect constrained node servers to come up with short URIs.
Existing designs based on CoAP (such as OMA lightweight M2M) go to great pains to keep their sizes in check.

So, no, I don't expect a realistic use case where the total length of options (which might be dominated by the URI) is greater than the IP MTU, not even the IFMUALTU (draft-bormann-intarea-alfi).

I should mention that the CoAP approach to slicing a large request/response pair into multiple exchanges is draft-ietf-core-block, which is widely implemented, but the specification text is not yet completed by the WG; if we ever need to address such a use case, we probably should address it there.  (As of today, -block only addresses slicing up the payload.)

Grüße, Carsten

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 27 Mar 2013 13:07:00 +0900

Hi Carsten,

> So, no, I don't expect a realistic use case where the total length of options (which might be dominated by the URI) is greater than the IP MTU, not even the IFMUALTU (draft-bormann-intarea-alfi).

Agreed.

> I should mention that the CoAP approach to slicing a large request/response pair into multiple exchanges is draft-ietf-core-block, which is widely implemented, but the specification text is not yet…

That's the point.  I hope that CoAP transport layer itself would have to have an ability of fragment/reassemble of the CoAP REST layer.  Maybe in the future, "option 0" would be responsible to do that.

Shoichi