Re: [core] CoRE v/s Compressed HTTP

["Don Sturek" <[e-mail]>]

Hi Zach,

On the length, for IEEE 802.15.4 using 6LowPAN, I think we have around 50 or
so bytes to work with in the first block (application wise).  If that fits
all the data you want to send that is great.  However, many solutions need
more.  Even if the application architects its control packets to fit into
those 50 bytes, the application may need to do reporting/etc which will
cause at least a portion of those packets to be fragmented.

Don


-----Original Message-----
From: Zach Shelby [mailto:[e-mail]] 
Sent: Friday, July 02, 2010 5:58 AM
To: [e-mail]
Cc: 'Guido Moritz'; [e-mail]; [e-mail]
Subject: Re: [core] CoRE v/s Compressed HTTP

Morning Don,

On Jul 2, 2010, at 3:50 PM, Don Sturek wrote:

> Hi Zach,
> 
> I think what you wrote is not quite correct.
> 
> I think many solutions will need guaranteed delivery

Agreed, and we have that.

> and I think many will
> need fragmentation/reassembly.  

This is something we still need to experiment with and gain experience. Can
applications that need that do it themselves? Or is the Block Option
proposal in coap-misc-04 workable? If the WG concludes that we need it and
we have a way to do it then we surely will.

> Only a small subset of solutions will work
> with CoAP/UDP and all application messaging fitting into a single packet.

How did we go from transferring payloads in the sizes of 10s of bytes, to
several kBs in this WG? ;-) coap-01 requires this to fit in a single MTU,
which would usually be between 1280-1500 bytes. At least for all the
applications I have experience with in the 6LoWPAN world this is sufficient.
For the few things like firmware transfer that need more, you can design a
REST interface for that. What do you have in mind?

> 
> The reason I mention this is that I fully expect to see a need in some of
> the features that TCP offers though I agree that congestion control in a
> mesh network is not one of them (at least as implemented in TCP).

Yep, Lars's document has a really good list of stuff we need to experiment
with and integrate into the base coap document as they are verified. We hope
to try some out already at the plugfest.

Zach

> 
> Don
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
Zach
> Shelby
> Sent: Friday, July 02, 2010 3:50 AM
> To: Guido Moritz
> Cc: [e-mail]; [e-mail]
> Subject: Re: [core] CoRE v/s Compressed HTTP
> 
> Regarding UDP and congestion control, I really think everyone should read
> the contribution from Lars:
> 
> http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt
> 
> One main point is that the whole congestion control model of TCP wouldn't
> really help us, the flow model is totally different here. The other issue
we
> have in CoRE is that not all requests even need to be (or should be)
> reliable - e.g. multicast or streaming.
> 
> The current coap-01 limitation on CoAP message size is that the resulting
> datagram must fit into the MTU. For 95% of the cases this payload size is
> sufficient. For that 5% (firmware update?), which I am personally not sure
> we should optimize for, coap-misc-04 does have a proposed block option to
> enabled transferring blocks of a representation. This is something to
> experiment with. 
> 
> Zach
> 
> On Jul 2, 2010, at 1:26 PM, Guido Moritz wrote:
> 
>>> "Clearly, some effort at the lower levels to improve network reliability
>>> can have a significant effect on
>>> application performance."
>> Jep, but from the CoAP point of view I would say this is what brings us
>> closer to UDP than to TCP. TCP uses ACKs and Retransmissions to get some
>> kind of reliability. But keep in mind that CoAP (and I assume it does)
has
>> no huge packets on application layer.  Of course, if application layer
>> packets are much bigger than transport layer packets, the ACK/Retr
> mechanism
>> on transport layer is a huge advantage concerning performance issues. But
> I
>> think CoAP is more heading towards smaller packets. So packet size on
>> application and transport layer might have the same size and thus an
>> application packet fits in one transport packet. So there would be no
need
>> for the TCP ACK/Retr of stuff TCP and you can do this on application
layer
>> directly with the same efforts and higher degree of reliability ('Did it'
>> vs. 'Got it'). So the main question at this point: which message/packet
>> sizes do we assume for a single request/response/transmission/what ever.
>> 
>> The other side of the coin would the checksum mechanism of TCP. Do we
want
>> to use this on our nodes or leave this up to other layers?
>> 
>> The last thing is the flow control/sliding window stuff. I think we will
> not
>> really need this in CoAP due to quite small receive/send buffers implied
> by
>> the resource constraints.
>> 
>> Guido
>> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: [e-mail] [mailto:[e-mail]]
>>> Gesendet: Freitag, 2. Juli 2010 11:37
>>> An: Guido Moritz
>>> Cc: [e-mail]
>>> Betreff: RE: [core] CoRE v/s Compressed HTTP
>>> 
>>> Yes, only a high-layer check can guarantee that what was sent is what
was
>>> received, without corruption.
>>> But to quote saltzer et al.:
>>> "Clearly, some effort at the lower levels to improve network reliability
>>> can have a significant effect on
>>> application performance."
>>> So transport-layer data consistency can benefit implementations.
>>> 
>>> It's a series of tradeoffs and engineering decisions, not necessarily
>>> clear-cut.
>>> 
>>> L.
>>> 
>>> There is no end to the end-to-end argument.
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Guido Moritz
>>> Sent: 02 July 2010 10:25
>>> 
>>> [..]
>>> (2) CoAP want's to use UDP instead of TCP. First I also did not found an
>>> obvious reason, until I read Saltzer et al. [1]. As long as we not need
>> the
>>> flow control mechanisms of TCP and we keep the packet sizes reasonable
>>> small enough, the only task of the transport layer is the transport
>> itself.
>>> Data consistency is not the task of the transport layer. ACK must be
done
>>> on the application layer if you really want to be sure your message has
>>> been processed.
>>> [..]
>> 
>> 
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
> 
> -- 
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: [phone]
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]