Subject: [core] draft-ietf-core-coap-06 Fragmentation

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 May 2011 20:45:44 -0600

Right now a node on fast v6 network will end up sending packets a bit over 1024 in size. If this packet is then sent to an 802.15.4 network, it could be fragmenting it down in 8 packets, each sent over multiple hops, each with say a packet loss of a few percent. This does not seem like it is going to work very well. This protocol is meant to work well on constrained networks and 15.4 is certainly one of the targets environments. 

I can see two ways to fix this. 1) mandate path MTU discover or 2) use a smaller MTU. I think 1 (PMTUD) would be hard, add complexity, and make things slower to get going - I don't like that so I prefer the using a smaller packet size. It''s hard to pick a number, but lets just say you 240 or something like that. That would make it so the packet would probably not result in more than 2 fragments on an 15.4 network. For doing bulk transfers of something like firmware using block, the difference in efficiency between the 1023 and 240 seems pretty small to me so I don't see a big downside of using smaller packets. (240 was just pulled out of thin air - I'm sure a little thought would lead to a better number). I don't have a strong opinion on how to fix this or if 240 is the right number, but I feel strongly that a CoAP node on a server with fast ethernet needs to be able to talk to a CoAP node on 15.4 mesh network and have that work well. 

Cullen <in my role as an individual contributor>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 May 2011 07:40:50 +0200

On May 5, 2011, at 04:45, Cullen Jennings wrote:

> Right now a node on fast v6 network will end up sending packets a bit over 1024 in size. 

I don't agree with that premise.

The fact that the protocol allows you to use large messages does not mean that end-points are forced to do that.

Completely outlawing large messages is the wrong solution to this problem.

The more interesting question is how does a node that would like to use large messages find out that this would be appropriate.  Indeed, we don't have a good answer on that.  Worse, the way adaptation layer (6LoWPAN) fragmentation is transparent means that there is absolutely no way to find out how to avoid adaptation fragmentation (see section 2.7.2 of the 6LoWPAN book).

I think this is a separate issue that we won't solve in this protocol.

On the editorial level, it probably wouldn't hurt to have text that guides the implementer to not blindly send large messages.  I have created ticket #148.

Gruesse, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 May 2011 12:29:15 -0600

> I don't agree with that premise.

Bottom of page 13 has a if the path mtu is not known, assume 1280 and then goes on to tell implementers to use 11152 and 1024. Have a look, perhaps I am just reading this the wrong way. 

> The fact that the protocol allows you to use large messages does not mean that end-points are forced to do that.

The spec can tell you the limits on what you may do but it also needs to tell you what to do such that if you implement the spec it will be useful. 

> Completely outlawing large messages is the wrong solution to this problem.

I was not proposing outlawing large message if you had something like path mtu discover, I was saying that when you did not have PTMUD, we had already outlawed larges messages by setting the limit to 1280 but that the number 1280 was too large and we needed a smaller number. We already had outlawed large messages when there is no PTMUD, we are just discussing the price, I mean size. 

> I think this is a separate issue that we won't solve in this protocol.

Agree, I'm not a fan of trying to define a workable PTMUD algorithm in this specification.

> On the editorial level, it probably wouldn't hurt to have text that guides the implementer to not blindly send large messages.  I have created ticket #148.

What I am looking for is enough advice in the spec that an implementor will end up implementing something that works in the use case I mentioned.