Re: [core] CoRE v/s Compressed HTTP

Hello All,

I think a key thing to remember about CoAP is that since it is using a RESTful approach to access resources, those same resources should be accessible by with normal HTTP over TCP. 

So for example CoAP can safely have a maximum size of say 1280 bytes. It prevents people from using CoAP for things it wasn't designed for by not even pretending to support them. To do firmware transfers for instance CoAP could at least point to a resource that can be accessed with something like FTP/TFTP etc. 

A node which is going to be routinely doing larger than 1280 byte transfers is probably not very constrained. Such a node will realistically be able to implement TCP/HTTP and can thus easily take advantage of all the features TCP supports. 

Keeping CoAP intensely focused on the constrained devices should make it possible to implement on those constrained devices. 

Regards,

  -Colin

-----Original Message-----
From: core-bounces@ietf.org on behalf of Zach Shelby
Sent: Fri 02/07/2010 16:44
To: d.sturek@att.net
Cc: core@ietf.org; L.Wood@surrey.ac.uk
Subject: Re: [core] CoRE v/s Compressed HTTP

Please read http://tools.ietf.org/id/draft-eggert-core-congestion-control-00.txt and then let's talk more about this, I found this a very useful draft. I think we all agree that features for rate control, congestion control and reliability that suit our charter requirements are needed. 

Regarding TCP we already had WG consensus to remove that from the scope of our work for now.

Zach

On Jul 2, 2010, at 5:53 PM, Don Sturek wrote:

> Hi Robby,
> 
> Agree completely on flow control in TCP.
> 
> I guess my point is almost immediately after finishing CoAP over UDP, we
> will begin to add back features of TCP.  I would list
> fragmentation/reassembly, guaranteed delivery and flow control into that
> list.
> 
> Don
> 
> 
> -----Original Message-----
> From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of
> Simpson, Robby (GE Energy Services)
> Sent: Friday, July 02, 2010 6:46 AM
> To: Guido Moritz; L.Wood@surrey.ac.uk
> Cc: core@ietf.org
> Subject: Re: [core] CoRE v/s Compressed HTTP
> 
>> 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.
> 
> I think its useful to discuss flow control and congestion control
> separately (they are, in fact, quite different).
> 
> I agree that many of the existing TCP congestion control algorithms have
> less-than-ideal behavior on wireless meshes, for instance.  I further
> agree that if we keep the number of packets low and avoid links that
> have other flows, we may be able to get away with some less
> sophisticated congestion control algorithms for CoAp.
> 
> Flow control, on the other hand, may be quite useful for constrained
> devices.  As an example, my understanding is that the TCP flow control
> logic was intended to prevent more constrained devices from being
> overwhelmed by less constrained devices.  TCP's advertisement of
> essentially free buffer space in the receiver is one useful way to
> achieve flow control.  I would suggest we not dismiss such functionality
> as even amongst constrained devices some devices may be able to process
> 2 packets whereas another device may be able to process 3.
> 
> - Robby
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> 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: +358 40 7796297

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core