Re: [core] CoRE v/s Compressed HTTP

[Zach Shelby <[e-mail]>]

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]