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