Subject: [core] HTTP over UDP

From: Mark Baker <[email-masked]>
Date: Fri, 26 Mar 2010 12:07:13 -0400

Hello.  I've seen a handful of HTTP-like protocols over UDP proposed,
but I'm curious why I haven't seen any mention of doing plain old HTTP
over UDP, like this;

http://tools.ietf.org/html/draft-goland-http-udp-00

Has such an approach been considered and rejected?

Mark.

---

From: Robert Cragie <[email-masked]>
Date: Fri, 26 Mar 2010 09:15:39 -0700

It would seem reasonable to do this but HTTP is quite verbose so the aim 
is to compress the verbose text-based HTTP along with the content, which 
means that a request/response is more likely to fit into a UDP datagram, 
which is the aim for constrained environments.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 26/03/2010 9:07 AM, Mark Baker wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: <[email-masked]>
Date: Fri, 26 Mar 2010 16:20:24 +0000

UDP doesn't have the necessary streaming semantics; as soon as the message
exceeds one UDP segment, more than UDP can provide is needed.

There has been discussion elsewhere of splitting HTTP from TCP
and running HTTP over other protocols, including UDP-based protocols
that implement the necessary streaming.

See
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn

L.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: 26 March 2010 16:07
To: core
Subject: [core] HTTP over UDP

Mark.

---

From: Mark Baker <[email-masked]>
Date: Fri, 26 Mar 2010 14:09:47 -0400

Robert,

On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie
<[email-masked]> wrote:
> It would seem reasonable to do this but HTTP is quite verbose so the aim is
> to compress the verbose text-based HTTP along with the content, which means
> that a request/response is more likely to fit into a UDP datagram, which is
> the aim for constrained environments.

I understand.  I just wanted to check that there wasn't any explicit
requirement being violated.

FWIW, this group isn't the first to want to do HTTP-like things in a
constrained environment.  The WAPforum developed a whole stack of
HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively
deprecate them in 2001, replacing them with the real deal.  If
anybody's interested, here's their HTTP-like protocol, WSP;

http://www.openmobilealliance.net/technical/release_program/docs/Browser_Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf

The target environment for CoRE is obviously different from that of
WAP in some ways, but I think the lesson is the same.

Mark.

---

From: <[email-masked]>
Date: Fri, 26 Mar 2010 18:14:49 +0000

http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html

section 2.5 covers WSP - and BEEP has similar territory, these days.

What lessons do you think WAP taught us?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: 26 March 2010 18:10
To: robert.cragie
Cc: core
Subject: Re: [core] HTTP over UDP

Robert,

On Fri, Mar 26, 2010 at 12:15 PM, Robert Cragie <[email-masked]> wrote:
> It would seem reasonable to do this but HTTP is quite verbose so the 
> aim is to compress the verbose text-based HTTP along with the content, 
> which means that a request/response is more likely to fit into a UDP 
> datagram, which is the aim for constrained environments.

I understand.  I just wanted to check that there wasn't any explicit requirement being violated.

FWIW, this group isn't the first to want to do HTTP-like things in a constrained environment.  The WAPforum developed a whole stack of HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively deprecate them in 2001, replacing them with the real deal.  If anybody's interested, here's their HTTP-like protocol, WSP;

The target environment for CoRE is obviously different from that of WAP in some ways, but I think the lesson is the same.

Mark.

---

From: "Stuber, Michael" <[email-masked]>
Date: Fri, 26 Mar 2010 11:30:01 -0700

It's a good point, but the mobile guys have had the advantage of
continuingly increasing capabilities at the handset and the network, and
a fast refresh cycle.  Right now there are around 35 million meters
under contract which will have 802.15.4 radios, and are expected to have
a minimum service life of 15 years -- 20 in most cases.  Deployment is
moving forward apace, and the majority of these will be in place by
2012.  I full recognize that we may move to the "real deal" on a future
generation, but we need CoAP to service what is being installed today.

Besides, about the time that today's "internet of things" has taken the
leap into bigger CPUs, faster networks, and generally less constrained
devices, somebody will decide that want to do IPv6 to cardboard boxes or
shoes, or something else where costs will dictate the use of tiny
constrained parts -- ones that will presumably be an order of magnitude
cheaper at that point.  I think they'll be uses for CoAP for a very long
time.  As long as we continue to push technology into smaller, cheaper,
and more ubiquitous locations, it can add value.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Baker
Sent: Friday, March 26, 2010 11:10 AM
To: robert.cragie
Cc: core
Subject: Re: [core] HTTP over UDP

Robert,

FWIW, this group isn't the first to want to do HTTP-like things in a
constrained environment.  The WAPforum developed a whole stack of
HTML/HTTP/TCP/TLS-like protocols in the late 90s, only to effectively
deprecate them in 2001, replacing them with the real deal.  If anybody's
interested, here's their HTTP-like protocol, WSP;

http://www.openmobilealliance.net/technical/release_program/docs/Browser
_Protocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf

The target environment for CoRE is obviously different from that of WAP
in some ways, but I think the lesson is the same.

Mark.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Mar 2010 11:33:59 -0700

> What lessons do you think WAP taught us?

One could write a book about that.
The most significant contributor to the failure of WAP was the attempt to reinvent HTML (i.e., WML).
Also contributing:
-- heavy mission creep (WAP was originally designed to run atop SMS!)
-- error 33 -- see http://en.wikipedia.org/wiki/Error_33
-- failure to anticipate the importance of IP

CoRE is set up with a view to not making any of these mistakes.

Gruesse, Carsten

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 26 Mar 2010 11:35:15 -0700

Actually, WAP taught us a few very important lessons (having worked in
cellular in the past):
1)  There is an actual market for web services on phones.  While obvious
today, it was not obvious at the time
2)  Chipset vendors and handset vendors can actually produce platforms that
can support things like full HTML, HTTP, etc in a cost effective manner that
meets the cost demands of the consumer space and contain features that
people will pay for.

I don't think any of the above was obvious when WAP was born.  I am unclear
todays HTTP/HTML phones would have existed without the experience of the
cellular industry with WAP.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, March 26, 2010 11:15 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [core] HTTP over UDP

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Baker
Sent: 26 March 2010 18:10
To: robert.cragie
Cc: core
Subject: Re: [core] HTTP over UDP

Robert,

http://www.openmobilealliance.net/technical/release_program/docs/Browser_Pro
tocol_Stack/V2_1-20050204/OMA-WAP-TS-WSP-V1_0-20020920-C.pdf

The target environment for CoRE is obviously different from that of WAP in
some ways, but I think the lesson is the same.

Mark.

---

From: Shidan Gouran <[email-masked]>
Date: Fri, 26 Mar 2010 14:49:16 -0400

The cellular industry had the freedom to evolve with market demands,  
utilities don't have this freedom, we are stuck with whatever is  
defined today for atleast another decade after deployment. I think  
that's why it's more important to plan this out a bit further.  
Defining officially Interfaces to HTTP, SIP and XMPP won't hurt with  
this and probably help quite a bit in fact.

I think, as currently defined, Coap might become the end to end  
standard for a significant number of deployments and it's not the  
optimal standard for this purpose.

Sent from my phone

On Mar 26, 2010, at 2:35 PM, "Don Sturek" <[email-masked]> wrote:

> anybody's
> WAP in

---

From: Mark Baker <[email-masked]>
Date: Fri, 26 Mar 2010 14:57:55 -0400

> What lessons do you think WAP taught us?

Primarily, that deviating from existing, pervasively deployed
standards, has very large costs.

FWIW, the two biggest deviations which killed WAP - speaking as
somebody who was actively involved in steering WAP towards the
W3C/IETF stack - were WML, which HTML developers were not interested
in learning, and the lack of an end-to-end security solution since
WSP/WTLS traffic had to converted and re-encrypted to HTTP/TLS at a
carrier gateway.

Mark.

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 26 Mar 2010 15:28:05 -0400

I am sorry for not understanding, but what is the "it" that's "not the
optimal standard for this purpose" in your last sentence below?

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shidan Gouran
Sent: Friday, March 26, 2010 2:49 PM
To: [email-masked]
Cc: [email-masked]; <[email-masked]>
Subject: Re: [core] HTTP over UDP

Sent from my phone

---

From: Shidan Gouran <[email-masked]>
Date: Fri, 26 Mar 2010 17:31:18 -0400

CoRe as an end to end protocol on the AMI network.

Sent from my phone

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 26 Mar 2010 14:38:58 -0700

Hi Michael,

A couple of points on your note:
1)  While smart meters are being deployed now, HAN devices to communicate to
them are not quite yet.  It won't be only meters that will communicate with
these HAN devices.  I could see deployment of full HTTP/TCP in HAN devices
that use access points that are not the meter supporting full web services
2)  Not all smart meters being deployed now are constrained and can also
support full HTTP/TCP.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stuber, Michael
Sent: Friday, March 26, 2010 11:30 AM
To: Mark Baker; robert.cragie
Cc: core
Subject: Re: [core] HTTP over UDP

-----Original Message-----

Robert,

Mark.

---

From: "Stuber, Michael" <[email-masked]>
Date: Fri, 26 Mar 2010 14:56:19 -0700

Don, I realize that you and I disagree on this, but my point about 35
million units with 802.15.4 was specifically about 802.15.4.  I feel
that HTTP/TCP is an inappropriate technology on 802.15.4 HAN devices,
regardless of the resources backing it.  I believe that large
multi-packet transactions that will be required when running HTTP/TCP
over 802.15.4 will not scale well, hence my strong interest in CoAP.

You raise a very good point though, the 35 million devices I reference
is just the tip of the iceberg.  These smart meters will be the first
wave, with many, many additional devices connecting to them.

-----Original Message-----
From: Don Sturek [mailto:[email-masked]] 
Sent: Friday, March 26, 2010 2:39 PM
To: Stuber, Michael; 'Mark Baker'; 'robert.cragie'
Cc: 'core'
Subject: RE: [core] HTTP over UDP

Hi Michael,

A couple of points on your note:
1)  While smart meters are being deployed now, HAN devices to
communicate to them are not quite yet.  It won't be only meters that
will communicate with these HAN devices.  I could see deployment of full
HTTP/TCP in HAN devices that use access points that are not the meter
supporting full web services
2)  Not all smart meters being deployed now are constrained and can also
support full HTTP/TCP.

Don

-----Original Message-----

Robert,

Mark.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 30 Mar 2010 16:20:24 -0500

Speaking as co-chair of PILC, which considered the WAP transport protocols 
and decided to focus on TCP instead ...

> WSP/WTLS traffic had to converted and re-encrypted to HTTP/TLS at a

I would agree that these were significant problems, and maybe even the top 
two.

I would add a third - "wishing that everything would fit in a datagram, even 
when we see problems with that on the horizon".

And I'm spending a decent amount of time as co-chair of MARTINI trying to 
unravel what we do when request (and, more seriously, response) sizes exceed 
what we can do in UDP, because a lot of SIP deployments don't handle the 
switch to TCP gracefully...

All I'm suggesting is that you guys make decisions about transport 
carefully.

Thanks,

Spencer

---

From: "Dave Horwitz" <[email-masked]>
Date: Tue, 30 Mar 2010 17:03:29 -0700

> Spencer Dawkins
> Sent: Tuesday, March 30, 2010 2:20 PM
> To: Mark Baker; L.Wood
> Cc: core
> I would add a third - "wishing that everything would fit in a
datagram,
> even

I've been confused about the "TCP optional" part since the meeting. It
was implied that if you wanted to do "some things" you might have to do
them using TCP. It was also said that TCP cannot (or will not) be
implemented on some constrained devices. How is this reconciled? And can
we define what "those things" are that can't/won't be done on the
constrained devices?

-Dave

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Mar 2010 09:10:59 +0200

On Mar 31, 2010, at 02:03, Dave Horwitz wrote:

> It
> implemented on some constrained devices. How is this reconciled?

One way to do this would be to say that TCP is optional for devices that don't deal in large resources, or (if we use my range request proposal) that can meaningfully use range requests to operate on any large resources (e.g., if these are just static descriptions or if there is some caching going on).

Personally, I'm indeed not sure most nodes *need* TCP.  TCP likely will be more efficient that any lock-step protocol based on range requests -- do we need that efficiency?  TCP also makes the state explicit that would be involved in a caching scheme, but there may be other ways to do that.  Again, I have not made up my mind yet.

Gruesse, Carsten

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 11:00:22 +0100

Well, wasn't at the meeting, but I can describe some constrained devices which do not implement TCP, because it's not efficient enough for the environment. So an alternative UDP-based protocol is used instead.

See
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga
http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga.html

Given implementations of TCP-friendly rate control (TFRC) in various protocols for when congestion control is needed, and moves to split e.g. HTTP from TCP and run it over other transports, I'm having trouble seeing where use of TCP would be a must.

L.

Lloyd Wood
http://tinyurl.com/lloydwood-ccsr
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dave Horwitz [[email-masked]]
Sent: 31 March 2010 01:03
To: core
Subject: Re: [core] HTTP over UDP

-Dave

---

From: "Oflynn, Colin" <[email-masked]>
Date: Wed, 31 Mar 2010 04:12:10 -0600

Hello,

I could imagine TCP being used on nodes which are handling either large frames (especially too large for UDP), or dealing with primarily streaming traffic where TCP makes more sense.

In both these cases a node which is "too constrained" to run TCP wouldn't be able to run these more demanding application protocols anyway. 

Regards,

   -Colin

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Wed 31/03/2010 11:00
To: [email-masked]; [email-masked]
Subject: Re: [core] HTTP over UDP

See

L.

Lloyd Wood

-Dave

---

From: "Dave Horwitz" <[email-masked]>
Date: Wed, 31 Mar 2010 15:15:51 -0700

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, March 31, 2010 12:11 AM
> To: Dave Horwitz
> Cc: core
> > It was implied that if you wanted to do "some things" 
> > you might have to do them using TCP. It was also said 
> > that TCP cannot (or will not) be implemented on some 
> > constrained devices. How is this reconciled?
> 
> One way to do this would be to say that TCP is optional 
> for devices that don't deal in large resources, 

This would require a definition of "large" and some way to 
identify devices that do or do not support large resources?

> or (if we use my range request proposal) that can meaningfully 
> use range requests to operate on any large resources (e.g., if
> these are just static descriptions or if there is some caching 
> going on).

This would work. I have not formed an opinion on the
complexity/efficiency/practicality of this, but it would work.

> Personally, I'm indeed not sure most nodes *need* TCP. 

My view is if any nodes *need* TCP then it's not "optional"
in the protocol and must be specified as required for those 
nodes. Otherwise it's implied that some requirement is not
being met?

> TCP likely will be more efficient that any lock-step protocol
> based on range requests - do we need that efficiency?  TCP also
> makes the state explicit that would be involved in a caching 
> scheme, but there may be other ways to do that.  Again, I have
> not made up my mind yet.
> 
> Gruesse, Carsten

-Dave