Re: [core] CoRE v/s Compressed HTTP

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

Hi Zach,

I think what you wrote is not quite correct.

I think many solutions will need guaranteed delivery and I think many will
need fragmentation/reassembly.  Only a small subset of solutions will work
with CoAP/UDP and all application messaging fitting into a single packet.

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).

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