Subject: [core] Link to multicast http I-D

From: Kerry Lynn <[email-masked]>
Date: Wed, 29 Sep 2010 12:09:55 -0400

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

-K-

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 17:18:50 +0100

The Goland draft mentioned below is a ten-year-old proposal.

Rather more useful and general than trying to specify http over UDP is breaking http from TCP as a separate layer, and then putting it over a variety of reliable transports, be they UDP-based, SCTP, TCP or otherwise.

Some notes on this and various pieces of work in this area are at:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into-a-standalone-layer-ietf-75-tsvarea-slides.pdf
Turning HTTP into a standalone layer: decoupling HTTP from TCP, talk given to the TSVAREA meeting, IETF 75, Stockholm, 27 July 2009.

and on
http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/http-dtn

delay-tolerant networking (DTN) provided a motivation for separating HTTP from TCP for environments where TCP fails, but the overall need to treat HTTP as a separate layer remains; just ignore the DTN-forwarding-specific Content- headers.

(meanwhile, Joe Touch would be interested in getting BGP off of only TCP, and onto e.g. SCTP... again, breaking coupling between layers in implementations with greater use of layering. HTTP really is a layer in its own right, and should be able to run over any reliable transport.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kerry Lynn
Sent: 29 September 2010 17:10
To: core
Subject: [core] Link to multicast http I-D

-K-

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 29 Sep 2010 12:23:57 -0400

Do any of this work specifically address the topic of multicast resource
manipulation?

-K-

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 17:35:11 +0100

"multicast resource manipulation" is not a topic per se.

HTTP-DTN was proposed as running over Saratoga (UDP + necessary reliability for large files and resend) and Saratoga supports multicast.
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga

You might also look into DDS, which is publish/subscribe CORBA middleware that does resource management and claims support of multicast as one of its transports.

http://www.opendds.org/transport.html
http://en.wikipedia.org/wiki/Data_Distribution_Service

-----Original Message-----
From: Kerry Lynn [mailto:[email-masked]] 
Sent: 29 September 2010 17:24
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [core] Link to multicast http I-D
Importance: High

Do any of this work specifically address the topic of multicast resource manipulation?

-K-

On Wed, Sep 29, 2010 at 12:18 PM,  <[email-masked]> wrote:
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-
> drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-turning-http-into
> -a-standalone-layer-ietf-75-tsvarea-slides.pdf
> (meanwhile, Joe Touch would be interested in getting BGP off of only 
> TCP, and onto e.g. SCTP... again, breaking coupling between layers in 
> implementations with greater use of layering. HTTP really is a layer 
> in its own right, and should be able to run over any reliable 
> transport.)
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Sep 2010 18:35:39 +0200

> The Goland draft mentioned below is a ten-year-old proposal.

I think we can all agree that we don't want to dig up this proposal as is.

We thought it might be useful to look at this because, in the CoRE webex call, we just had a little discussion what it means to do a REST operation on a multicast (or, maybe more generally speaking: group) authority.  If you have any input on how to address the obvious (and not so obvious) problems, that would be helpful.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 29 Sep 2010 19:53:27 +0300

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

I found this to have some interesting ideas, although obviously not applicable as-is. 

In particular Section 7 describes the use of the an mx header for requesting a random delay of 0 to mx before sending a response to avoid overflow. The draft also seems to assume that a multicast request is not made to a distributed authority, but to all authorities that happen to be listening to the IP address and port.

"When used with a multicast UDP HTTP request the "*" request-URI means "to everyone who is listening to this IP address and port."

Zach

> 
> -K-
> _______________________________________________
> core mailing list
> [email-masked]
> 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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Sep 2010 20:41:42 +0200

On Sep 29, 2010, at 18:53, Zach Shelby wrote:

> requesting a random delay of 0 to mx before sending a response

How do you choose that delay?
You need a group size estimate plus an estimate of the capacities of networks/nodes.
The former is hard to obtain with the distributed group membership management of IP multicast; the latter is essentially the congestion control problem, but with the slight complication that the path now is a tree.

(In a small and lightly-loaded network, some worst-case assumptions can carry quite far, though; e.g., section 5.5.4 of RFC 5740 gets by with simply assuming a group size estimate of 10000 is not worse than an order of magnitude wrong -- this would certainly be true with RFC 4944 16-bit addressing.)

Gruesse, Carsten