Subject: [core] Core UDP vs TCP : Redux

From: Thomas Herbst <[email-masked]>
Date: Tue, 11 May 2010 08:49:10 -0700

After the discussion in Anaheim, I'm surprised that we need yet another revisit to UDP and TCP for CORE.

The Right Solution(tm) might well be to fix TCP such that it doesn't lose its brains every time you drop a packet, and we could end up with an end-to-end system where constrained devices might reasonably provide services to normal hosts in the regular Internet,  However, transport work is out of scope for this WG.

The second most right solution would be to implement CORE with a reliable UDP protocol, as is done in much of the draft.  The "optional" TCP portions of the draft are mostly increased complexity for no added benefit. If a device is capable of running TCP and the network it works on is capable of supporting TCP, you should just open a connection to Port 80 and use HTTP (or the TCP port/protocol of your choice).  There are many protocols a host MAY implement and it is not appropriate for the draft to enumerate them.  

Let's remove all of the sections related to TCP in the draft.

tom

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 May 2010 11:09:00 -0700

> Let's remove all of the sections related to TCP in the draft.
Agreed.

-Doug

---

From: "Stuber, Michael" <[email-masked]>
Date: Tue, 11 May 2010 13:26:43 -0700

> Let's remove all of the sections related to TCP in the draft.
+1

---

From: Zach Shelby <[email-masked]>
Date: Wed, 12 May 2010 00:06:57 +0300

+1

Through writing a few revisions of these specs, I have also already found TCP to be really awkward. And the TCP negotiation discussions at the mike in Anaheim made me even more skeptical. Tom is right, if you need TCP then just use HTTP ;-) 

Zach 

On May 11, 2010, at 18:49 , Thomas Herbst wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Head of Research, 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: Tue, 11 May 2010 23:37:54 +0200

On May 11, 2010, at 23:06, Zach Shelby wrote:

> I have also already found TCP to be really awkward

(No WG chair hat)

The reason why I thought it would be a good idea to have TCP as an option in there was to fend off tendencies to reinvent TCP on top of UDP.  If we can agree not to do that, I'm certainly fine with throwing out TCP.  But once people do start to argue for reinventing TCP, we'll need to put the original back in.

(Rationale:
1) DTSTTCPW (Do the simplest thing that could possibly work.)
2) We can always put TCP back in later in a v2 of the protocol, once we know more about the applications and their real requirements from actual deployments and whether having TCP is a good thing.)

Gruesse, Carsten

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Tue, 11 May 2010 17:41:09 -0400

Carsten,

For clarification, what are your metrics for "reinventing TCP"?

Multiple packets?  Flow control?  Congestion control?

Thanks,
Robby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carsten Bormann
Sent: Tuesday, May 11, 2010 5:38 PM
To: Zach Shelby
Cc: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

(No WG chair hat)

The reason why I thought it would be a good idea to have TCP as an
option in there was to fend off tendencies to reinvent TCP on top of
UDP.  If we can agree not to do that, I'm certainly fine with throwing
out TCP.  But once people do start to argue for reinventing TCP, we'll
need to put the original back in.

(Rationale:
1) DTSTTCPW (Do the simplest thing that could possibly work.)
2) We can always put TCP back in later in a v2 of the protocol, once we
know more about the applications and their real requirements from actual
deployments and whether having TCP is a good thing.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 May 2010 23:52:56 +0200

> Multiple packets?  Flow control?  Congestion control?

Yes :-)

I don't have a problem with a multi-packet exchange to effect a transfer.
But we should be very careful with what kind of state we expect the two sides to build/maintain/keep for this.
Running a congestion control algorithm instead of a simple lock-step mechanism sounds wrong.
Having any kind of flow control beyond the lock-step (e.g., windows) sounds wrong.  
Having to establish a "session", "connection", "association" to effect the transfer sounds wrong.

But I don't think of these as metrics, so if a good way to have these multi-packet exchanges is proposed, let's look at the impact on nodes and network instead of trying to decide whether it is too much like TCP.

What do you think?

Gruesse, Carsten

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 May 2010 18:02:03 -0400

This works as long as you can guarantee that the response is < MTU. Doing your own fragmentation is a pain (you are then well on your way to re-inventing TCP) and relying on IP fragmentation is unlikely to work in "challenged" networks. Thus, these applicability limitations need to be spelled out very clearly. This also has security implications - obviously, TLS is out without TCP, but anything involving certificates is also likely to be difficult to carry.

Henning

---

From: Thomas Herbst <[email-masked]>
Date: Tue, 11 May 2010 18:11:25 -0700

On TCP vs UDP - we need to pick one.  Deciding to use both UDP and TCP is just not making a decision.  

You expect people who didn't include enough memory in their devices to implement TCP to do both UDP and TCP? 

On security, is there a problem w/ DTLS?

tom

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 3:02 PM
To: Zach Shelby
Cc: Thomas Herbst; [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Henning

---

From: "Oflynn, Colin" <[email-masked]>
Date: Tue, 11 May 2010 19:13:32 -0600

Hello,

>This works as long as you can guarantee that the response is < MTU.

Which the current draft does. If we go the UDP route, I think we need to add support for larger packets through some simple fragmentation.

You won't need such large packets often! So it doesn't have to be very efficient, just every so often you need to transmit a large frame for a file load, encryption, etc. 

Regards,

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Thomas Herbst
Sent: Wed 12/05/2010 02:11
To: Henning Schulzrinne; Zach Shelby
Cc: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

tom

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2010 3:02 PM
To: Zach Shelby
Cc: Thomas Herbst; [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 May 2010 21:41:09 -0400

All I can say is that a lot of people thought that when we designed SIP - and I think it's clear that the assumption turned out to be wrong enough to cause grief. Doesn't mean that it will here, but I'd suggest some realization that our collective crystal ball is a bit fuzzy. Protocols, particularly successful ones, tend to get pushed to their limits and beyond. (If you want, DNS, tftp and RSVP are other examples where one could argue that this has caused significant pain.)

Just to spin this direction forward: If you want fragmentation and reliability, you have to be able to ack request individual fragments, as you'll otherwise end up retransmitting the whole frame if one fragment is lost, plus a total length field (so that the sender knows whether to expect more fragments). Not overwhelming complexity, but probably doubles the header size.

Henning

---

From: Douglas Otis <[email-masked]>
Date: Tue, 11 May 2010 19:13:17 -0700

> Running a congestion control algorithm instead of a simple lock-step mechanism sounds wrong.
A byte stream is not a good approach in resource limited environments.  
However, framed data objects should not be exchanged in lock-step 
fashion either.  By not requiring ordered delivery, offset with an 
ability for direct placement, buffering can be minimal.  TLV framed 
exchanges can be regulated by chunks containing acks, credits with noted 
gaps and dups, for example.  Whether this information is used to 
establish reliable delivery should be left to the application.  The 
underlying transport can be kept simple, with perhaps negotiated 
dependence on whether the sender is to retry non-critical data.  The 
protocol should be able to avoid congestion without being limited to 
lock-step exchanges as well.
> Having any kind of flow control beyond the lock-step (e.g., windows) sounds wrong.
Disagree.  These networks might be slow and may make use of 
multi-casting.  Information exchange is not best done in lock-step, nor 
as a byte steam.
> Having to establish a "session", "connection", "association" to effect the transfer sounds wrong.
Both security, performance, and reliability benefit by having more than 
just TFTP style exchanges.
> But I don't think of these as metrics, so if a good way to have these multi-packet exchanges is proposed, let's look at the impact on nodes and network instead of trying to decide whether it is too…
Framed data objects with selective acks can make the best use of limited 
resources and slow networks, where TCP does not fit this mode of 
operation.  It should also be noted that TLS remains possible without TCP.

-Doug

---

From: <[email-masked]>
Date: Wed, 12 May 2010 07:25:33 +0100

> But I don't think of these as metrics, so if a good way to have these multi-packet exchanges is proposed, let's look at the impact on nodes and network instead of trying to decide whether it is too…

Some sort of connection is needed to deal with multi-packet exchanges.

Sounds like the basic principles that went into designing Saratoga for UDO:
http://tools.ietf.org/html/draft-wood-tsvwg-saratoga-05
http://info.ee.surrey.ac.uk/Personal/L.Wood/dtn/saratoga

L.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: "Oflynn, Colin" <[email-masked]>
Date: Wed, 12 May 2010 06:03:10 -0600

Hello,

Do the limitations of a lock-step transfer matter in our limited networks? 

I see it like this: lock-step will have tiny code size. It is very very simple to implement and understand. I don't see every transmission being multi-packet, very very few transmissions would exceed the 1280 byte limit using UDP. Most people doing consistently large packets would probably be using real TCP or something else. What we want to define is something that lets CoAP work with large packets, but is NOT supposed to be used to stream video.

When using CoAP that gives you reliability anyway, as you get the HTTP/CoAP/OK in response. If you send a single packet, and you get OK, then it all worked. It's only when you have a multi-packet message you get into trouble, since you'd have to resend the entire message if you don't get OK.

As a code-size comparison: 6lowpan-hc takes around 6K flash on an AVR device, but it gives you considerable compression that you use on *every* packet. So this makes it very very useful, and worth 6K. 

Regards,

   -Colin

PS: The HSS Saratoga looks like much warmer diving then we've got in the UK ;-)

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Wed 12/05/2010 07:25
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

L.

Lloyd Wood
[email-masked]

---

From: Guido Moritz <[email-masked]>
Date: Wed, 12 May 2010 15:53:32 +0200

Sorry, but I would not agree to say 'when you are able to use TCP, you are
also able to use HTTP'. We made several measurements with UDP vs. TCP and of
course, connection setup takes longer for TCP. But a typical HTTP header has
a size >100 Byte (without any payload). Thus the connection setup overhead
is compensated due to large payload/headers itself. There might be
application scenarios where the designer wants to have reliable
communication, but still have small payload.

I did not have read through the current core I-D extensively, but is it
necessary to go so much into detail why to use UDP or TCP and how it should
be used? It might be reasonable to define a reliability (and maybe also
fragmentation) extension to UDP and define UDP as the defualt, but why
should TCP be forbidden at all?

One may argue about SOAP Web services in several points, but their binding
concept is quite nice. SOAP can be bound to which transport mechanism ever.
This makes it applicable it different scenarios and the transport
mechanisms/protocol can be changed without an effect on application itself.

Just my two cents,
Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Zach
> Shelby
> Gesendet: Dienstag, 11. Mai 2010 23:07
> An: Thomas Herbst
> Cc: [email-masked]
> Betreff: Re: [core] Core UDP vs TCP : Redux
> 
> +1
> 
> Through writing a few revisions of these specs, I have also already found
TCP
> to be really awkward. And the TCP negotiation discussions at the mike in
> Anaheim made me even more skeptical. Tom is right, if you need TCP then
just
> use HTTP ;-)
> > The Right Solution(tm) might well be to fix TCP such that it doesn't
lose
> its brains every time you drop a packet, and we could end up with an
end-to-
> end system where constrained devices might reasonably provide services to
> normal hosts in the regular Internet,  However, transport work is out of
scope
> for this WG.
> >
> > The second most right solution would be to implement CORE with a
reliable
> UDP protocol, as is done in much of the draft.  The "optional" TCP
portions of
> the draft are mostly increased complexity for no added benefit. If a
device is
> capable of running TCP and the network it works on is capable of
supporting
> TCP, you should just open a connection to Port 80 and use HTTP (or the TCP
> port/protocol of your choice).  There are many protocols a host MAY
implement
> and it is not appropriate for the draft to enumerate them.
> >

---

From: <[email-masked]>
Date: Wed, 12 May 2010 15:28:10 +0100

HTTP doesn't _have_ to run over TCP:
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-05
and decoupling HTTP from TCP would be a very good idea, as implementation work to do so (e.g. HTTP over SCTP) is ongoing:
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html#http-standalone

The only SOAP binding I can find is that to HTTP:
http://www.w3.org/TR/soap12-part2/#soapinhttp
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew

which does place SOAP binding firmly at 'concept' stage - one example to claim that an entire range of possibilities exist and are implementable.

Another example of this 'concept' is BEEP's transport profiles, for which only a mapping to TCP is actually defined. Because nobody uses BEEP.

L.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guido Moritz
Sent: 12 May 2010 14:54
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Sorry, but I would not agree to say 'when you are able to use TCP, you are also able to use HTTP'. We made several measurements with UDP vs. TCP and of course, connection setup takes longer for TCP. But a typical HTTP header has a size >100 Byte (without any payload). Thus the connection setup overhead is compensated due to large payload/headers itself. There might be application scenarios where the designer wants to have reliable communication, but still have small payload.

I did not have read through the current core I-D extensively, but is it necessary to go so much into detail why to use UDP or TCP and how it should be used? It might be reasonable to define a reliability (and maybe also
fragmentation) extension to UDP and define UDP as the defualt, but why should TCP be forbidden at all?

One may argue about SOAP Web services in several points, but their binding concept is quite nice. SOAP can be bound to which transport mechanism ever.
This makes it applicable it different scenarios and the transport mechanisms/protocol can be changed without an effect on application itself.

Just my two cents,
Guido

Zach
TCP
> to be really awkward. And the TCP negotiation discussions at the mike 
> in Anaheim made me even more skeptical. Tom is right, if you need TCP 
> then
just
> > After the discussion in Anaheim, I'm surprised that we need yet 
> > another
> revisit to UDP and TCP for CORE.
> >
lose
end-to-
> end system where constrained devices might reasonably provide services 
> to normal hosts in the regular Internet,  However, transport work is 
> out of
scope
reliable
portions of
device is
supporting
> TCP, you should just open a connection to Port 80 and use HTTP (or the 
> TCP port/protocol of your choice).  There are many protocols a host 
> MAY
implement

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 08:31:04 -0600

> For clarification, what are your metrics for "reinventing TCP"?

Excellent question. 

The IETF has a pretty involved process for defining any new algorithms for transports. One of the reasons it is so involved is that people want to make sure that the new algorithm does not adversely impact existing transports.  Clearly this WG would be the wrong place to do any new algorithms. 

That still allows us to use algorithms that have been done for other things here. (For example, the tftp algorithm got mentioned in an earlier thread.) We will want to coordinate closely with the transport ADs on whatever we do but I don't see problems with simple reliability, or some simple fragmentation based around existing technique - several other WGs have done that.  We pretty much have to use one of the existing approaches to congestion control. 

I suspect that if we started talking about features to improve the transfer rate of data beyond the what simple algorithms give you, folks would start really wondering if it would be better to use TCP. I know that I would want to have a chat with the transport ADs before going down any path like that.

Cullen 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Oflynn, Colin" <[email-masked]>
Date: Wed, 12 May 2010 09:22:13 -0600

Hello,

For the record on TFTP (which I think such a style would be good for simple fragmentation):

In our testing, with a real 802.15.4 network in test code (read: not carefully optimized) we could get 5-7 Kbytes/sec with TFTP transferring large files. This is using standard 512-byte TFTP fragmentation size.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Cullen Jennings
Sent: Wed 12/05/2010 15:31
To: Simpson, Robby (GE Energy Services)
Cc: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Excellent question. 

Cullen 

Cullen Jennings

---

From: Robert Cragie <[email-masked]>
Date: Wed, 12 May 2010 22:46:04 +0100

If we specify UDP only as transport, for delivery we need to consider 
the following:

   1. UDP is adequate for the transport's client applications delivery as is
   2. The transport's client applications provides delivery mechanisms
      appropriately according to their requirements
   3. Creating a shim layer above UDP for improving delivery and
      providing a homogeneous interface to client applications
   4. Creating a framework (SASL-like), separating the protocols and the
      mechanisms to promote reuse across applications.

(1) may be the case in very simple delivery where it doesn't really 
matter if the odd packet gets lost, e.g. non-critical temperature 
readings. This could allow for very simple transmit-only devices. (2) 
would make sense but could mean implementing multiple similar but subtly 
different mechanisms multiple times in a device which serves different 
applications. These may be pretty simple, including lock-step 
transactions using 'short' packets, i.e. fitting into one UDP datagram. 
(3) seems to be frowned upon and seems that it may be out of scope for 
the WG, although would probably be more efficient on the basis that 
there is a common set of requirements for reliable delivery. (4) could 
work, providing a half-way between (2) and (3)

Back to (2), for example, DTLS implements its own reliability mechanism 
- could this be reused by other applications?

I think the framework idea might be worth exploring further although I 
am not entirely sure whether reliability mechanisms can be classified 
appropriately with common interfaces in this way.

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 12/05/2010 2:13 AM, Oflynn, Colin wrote:
> Which the current draft does. If we go the UDP route, I think we need 
> to add support for larger packets through some simple fragmentation.
>
> You won't need such large packets often! So it doesn't have to be very 
> efficient, just every so often you need to transmit a large frame for 
> a file load, encryption, etc.
>
> Regards,
>
>   -Colin
>
>
> Doing your own fragmentation is a pain (you are then well on your way 
> to re-inventing TCP) and relying on IP fragmentation is unlikely to 
> work in "challenged" networks. Thus, these applicability limitations 
> need to be spelled out very clearly. This also has security 
> implications - obviously, TLS is out without TCP, but anything 
> involving certificates is also likely to be difficult to carry.
>
> Henning
>
> > Through writing a few revisions of these specs, I have also already 
> found TCP to be really awkward. And the TCP negotiation discussions at 
> the mike in Anaheim made me even more skeptical. Tom is right, if you 
> need TCP then just use HTTP ;-)
> >
> > Zach
> >
> another revisit to UDP and TCP for CORE.
> >>
> >> The Right Solution(tm) might well be to fix TCP such that it 
> doesn't lose its brains every time you drop a packet, and we could end 
> up with an end-to-end system where constrained devices might 
> reasonably provide services to normal hosts in the regular Internet,  
> However, transport work is out of scope for this WG.
> >>
> reliable UDP protocol, as is done in much of the draft.  The 
> "optional" TCP portions of the draft are mostly increased complexity 
> for no added benefit. If a device is capable of running TCP and the 
> network it works on is capable of supporting TCP, you should just open 
> a connection to Port 80 and use HTTP (or the TCP port/protocol of your 
> choice).  There are many protocols a host MAY implement and it is not 
> appropriate for the draft to enumerate them.
> >>

---

From: "Oflynn, Colin" <[email-masked]>
Date: Thu, 13 May 2010 09:16:51 -0600

Hi Robert,

I think it makes sense to look at integrating such requirements into CoAP itself (or whatever higher level protocol is used). How TFTP for instance adds reliability & fragmentation onto UDP.

core-coap-01 does have an "acknowledgement" flag, which when sent with a request means it MUST generate a response. A simple fragmentation flag could be added perhaps to support larger messages. 

Which would be a combination of 3 & 4 maybe? Although I've not thought about it very hard, so if I'm missing something obvious about why this won't work be sure to call me out on that ;-)

Regards,

   -Colin

-----Original Message-----
From: [email-masked] on behalf of Robert Cragie
Sent: Wed 12/05/2010 22:46
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

---

From: Guido Moritz <[email-masked]>
Date: Mon, 17 May 2010 08:53:21 +0200

For example there is a SOAP-over-UDP binding defined at OASIS
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-dd
The intention is to carry UDP multicast and unicast discovery messages.

See also SOAP over SMTP http://www.pocketsoap.com/specs/smtpbinding/

However, what is interesting to be agnostic of the transport protocol and
define dependencies in such bindings and not in the protocol itself.

Guido

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Mittwoch, 12. Mai 2010 16:28
> An: Guido Moritz; [email-masked]
> Betreff: RE: [core] Core UDP vs TCP : Redux
> 
> and decoupling HTTP from TCP would be a very good idea, as implementation
work
> to do so (e.g. HTTP over SCTP) is ongoing:
>
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/talks.html#http
-
> standalone
> which does place SOAP binding firmly at 'concept' stage - one example to
claim
> that an entire range of possibilities exist and are implementable.
> 
> Another example of this 'concept' is BEEP's transport profiles, for which
only
> a mapping to TCP is actually defined. Because nobody uses BEEP.
> 
> L.
> 
Guido
> Moritz
> course, connection setup takes longer for TCP. But a typical HTTP header
has a
> size >100 Byte (without any payload). Thus the connection setup overhead
is
> compensated due to large payload/headers itself. There might be
application
> scenarios where the designer wants to have reliable communication, but
still
> have small payload.
> necessary to go so much into detail why to use UDP or TCP and how it
should be
> used? It might be reasonable to define a reliability (and maybe also
should
> TCP be forbidden at all?
> > found

---

From: [email-masked]
Date: Mon, 17 May 2010 12:41:21 +0000

Hi guido,

I think the thing is this is not soap but rest.  It is fine to create mappings but not to change the design goal of using rest.

Don
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Guido Moritz <[email-masked]>
Date: Mon, 17 May 2010 08:53:21 
To: <[email-masked]>
Subject: Re: [core] Core UDP vs TCP : Redux

Guido

> HTTP doesn't_have_ to run over TCP:
work
claim
only
Guido
has a
is
application
still
should be
should

---

From: Guido Moritz <[email-masked]>
Date: Mon, 17 May 2010 15:58:05 +0200

Don

REST (apples) is an architectural style, SOAP (oranges) is a protocol, hard
to compare apples and oranges. BTW, it is possible to use SOAP for a RESTful
design also. See WS-RA for example:
http://www.w3.org/2008/08/ws/charter.html 

But I didn't want to go to deep into this discussion. I just wanted to ask
if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or if
it is possible to leave this open and design CORE extensible and flexible
enough. This is anyway not related to REST, SOA or any other architecture,
just a question of protocol design.

Guido

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Montag, 17. Mai 2010 14:41
> An: Guido Moritz; [email-masked]; [email-masked]
> I think the thing is this is not soap but rest.  It is fine to create
mappings
> but not to change the design goal of using rest.
> 
> Don
> > also able to use HTTP'. We made several measurements with UDP vs. TCP
and
> of

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 May 2010 16:23:39 +0200

On May 17, 2010, at 15:58, Guido Moritz wrote:

> I just wanted to ask
> enough.

It may be hard to meet the working group's objective of addressing constrained node/networks while leaving the underlying protocol(s) open.  It may also be hard to meet this objective while inserting a subprotocol as complex as SOAP into the stack.

Gruesse, Carsten

---

From: [email-masked]
Date: Mon, 17 May 2010 14:47:45 +0000

Hi guido,

My point is that rest architecture mapped to on on protocol is not soap

Don

-----Original Message-----
From: Guido Moritz <[email-masked]>
Date: Mon, 17 May 2010 15:58:05 
To: <[email-masked]>
Subject: Re: [core] Core UDP vs TCP : Redux

Don

Guido

mappings
and

---

From: Guido Moritz <[email-masked]>
Date: Mon, 17 May 2010 17:11:14 +0200

> It may also be hard to meet this objective while inserting a subprotocol
as complex as SOAP into the stack.
I just went through the current COAP I-D and it is already quite complex! It
includes many mechanisms and concepts which are also included in SOAP and
other W3C/OASIS Web services specifications that I am familiar in due to my
background in DPWS. 

Nevertheless, let's leave the discussion around SOAP, because there seems to
be many misunderstandings related to SOAP and what I wanted to point at.
What I wanted to say is (and that is my still my opinion after reading
current COAP I-D): there is no reason to bind COAP to UDP or TCP exclusively
or exclude one of them. COAP seems to describe many mechanisms for
interaction with resources, eventing and discovery mechanisms, mechanisms to
avoid duplicated message processing etc. But all these mechanisms do not
depend on the transport layer. Why should a node not support interactions by
using TCP or UDP at the same time for the same resource. Of course, not the
highly resource constrained one, but we are heading towards heterogeneous
device infrastructures where resource richer devices in the same network
might be possible as well.

Take the ideas or throw them away. But these are major decisions concerning
applicability of the resulting COAP. What made HTTP and REST in the WWW such
a success was that it is possible to run it over all kinds of technologies
and not to restrict it to specific message sizes. Let's say there is a cool
new wireless technology IEEE 802.15.XY which is capable of running 6LoWPAN
but with double of the frame size and data rate at same energy costs. Will
there be the next COAPXY for this new link layer because suddenly there is
double the bandwidth available?

Again,
Just my two cents ;)
Guido

> Von: Carsten Bormann [mailto:[email-masked]]
> Gesendet: Montag, 17. Mai 2010 16:24
> An: Guido Moritz
> Cc: [email-masked]
> It may be hard to meet the working group's objective of addressing
constrained
> node/networks while leaving the underlying protocol(s) open.  It may also
be
> hard to meet this objective while inserting a subprotocol as complex as
SOAP
> into the stack.

---

From: "Charles Palmer" <[email-masked]>
Date: Mon, 17 May 2010 16:47:40 +0100

Hi folks

Worth noting that the draft ZigBee Smart Energy 2.0 Application Protocol Specification is very good about not mandating the transport layer (although it talks extensively about TLS - does this limit it to TCP?)

The SE2.0 spec also makes reference to possibly using CoRE (see quote below). BTW how closely are we/should we be tracking SE2.0 work? I see several names in both lists. I'd speculate that if CoRE is to be of use to ZigBee Smart Energy then CoRE needs to provide an easy transition.

I guess SE2.0 plans to use HTTP/EXI/TCP/IP because they exist and work. 

How disruptive would it be to design CoRE without reference to TCP/UDP, and also design a "reliable UDP" and use this for CoRE? 

>From SE2.0:

"6.1 Protocol Flexibility
The Smart Energy Profile is designed to implement a RESTful architecture. As such it is built around the core actions of GET, PUT, POST, and DELETE (as used in [REST]), with the addition of a lightweight subscription and notification mechanism, as discussed above in §7. It is not however, strictly limited to HTTP. Any protocol that can implement the GET, PUT, POST, and DELETE command set can be used with SEP 2.0. It is expected that HTTP is the preferred protocol for interactions with the broader Internet, and that protocol translation services are provided when it is desired to link an SEP system using another application protocol with HTTP based solutions. The lightweight RESTful Constrained Application Protocol (CoAP) is one such alternative to HTTP [COAP]. This protocol should be proxied to HTTP for interactions with the broader Internet, but may be applied end-to-end."

Regards - Charles Palmer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guido Moritz
Sent: 17 May 2010 16:11
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Again,
Just my two cents ;)
Guido

constrained
be
SOAP

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 17 May 2010 09:16:28 -0700

Hi Charles,

I think HTTP/TCP/IP/EXI was selected in Smart Energy 2.0 to provide a
familiar programming environment for the headend systems.  In general, we
(the SE 2.0 team) chose REST as the programming paradigm with HTTP/TCP as
"plan A" and CoRE/UDP as "plan B".  Plan B is around ensuring that the stack
fits on small footprint devices (particularly those already fielded).   We
(SE 2.0) are in the midst of interoperability testing of IEEE
802.15.4/6LowPAN/IPv6/TCP/HTTP so we should have some
throughput/efficiency/code size issues shortly.

In any case, we believe that CoRE is a fundamental feature needed to deploy
small footprint devices.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Palmer
Sent: Monday, May 17, 2010 8:48 AM
To: core
Subject: Re: [core] Core UDP vs TCP : Redux

Hi folks

Worth noting that the draft ZigBee Smart Energy 2.0 Application Protocol
Specification is very good about not mandating the transport layer (although
it talks extensively about TLS - does this limit it to TCP?)

The SE2.0 spec also makes reference to possibly using CoRE (see quote
below). BTW how closely are we/should we be tracking SE2.0 work? I see
several names in both lists. I'd speculate that if CoRE is to be of use to
ZigBee Smart Energy then CoRE needs to provide an easy transition.

How disruptive would it be to design CoRE without reference to TCP/UDP, and
also design a "reliable UDP" and use this for CoRE? 

"6.1 Protocol Flexibility
The Smart Energy Profile is designed to implement a RESTful architecture. As
such it is built around the core actions of GET, PUT, POST, and DELETE (as
used in [REST]), with the addition of a lightweight subscription and
notification mechanism, as discussed above in §7. It is not however,
strictly limited to HTTP. Any protocol that can implement the GET, PUT,
POST, and DELETE command set can be used with SEP 2.0. It is expected that
HTTP is the preferred protocol for interactions with the broader Internet,
and that protocol translation services are provided when it is desired to
link an SEP system using another application protocol with HTTP based
solutions. The lightweight RESTful Constrained Application Protocol (CoAP)
is one such alternative to HTTP [COAP]. This protocol should be proxied to
HTTP for interactions with the broader Internet, but may be applied
end-to-end."

Regards - Charles Palmer 

-----Original Message-----
Guido Moritz

Again,
Just my two cents ;)
Guido

constrained
be
SOAP

registered office is 6 Great Newport Street, London, WC2H 7JB, United
Kingdom.

This email message may contain confidential and/or privileged information,
and
is intended solely for the addressee(s). If you have received this email in

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 May 2010 18:58:52 +0200

> How disruptive would it be to design CoRE without reference to TCP/UDP, and also design a "reliable UDP" and use this for CoRE? 

I personally think CoAP needs to work with DTLS; if the WG moves in that direction there will be some minimum requirement for independence from the underlying protocol.

However, what we expect from the underlying protocol has a big bearing on CoAP itself.
If we expect we can always move to TCP, there will be little need to make CoAP operate on large representations with small underlying interactions.  I've heard a lot of pushback on assuming the availability of TCP, so far.

There is also the aspect of interoperability:  One of the great properties of the Web is that everybody uses the same stack, so all Web clients and servers are interoperable, with IP providing the necessary technological diversity.
(On the other hand, this has made it near impossible to swap in, say, SCTP.)
Just standardizing CoAP without an "we expect this to run on UDP, unless otherwise specified" would not achieve the same level of interoperability.

<WG chair hat>In any case, designing a reliable transport as a TCP replacement and then a CoAP on top of either that or TCP is very much not what the charter suggests we are supposed to do.</WG chair hat>
Instead, we should look at how stateless CoAP really can be made -- I think even TFTP has too much state (and thus isn't as trivial a file transfer protocol as it could be).

Gruesse, Carsten

---

From: "Stuber, Michael" <[email-masked]>
Date: Mon, 17 May 2010 15:30:11 -0700

Quoting:

"I guess SE2.0 plans to use HTTP/EXI/TCP/IP because they exist and work."

They exist and work on PCs and some embedded devices.  There are open questions as to how effective they will be in an 802.15.4 context, especially when packet size constraints, device constraints, and network scale are factored in.  (Note:  I'm not suggesting that HTTP doesn't work, I'm suggesting that a lighter-weight solution like CoAP is a better choice given the limitations in these networks, especially as they are required to scale up.)  That is why some of us are very interested in CoAP.  HTTP/EXI/TCP/IP can be made smaller with effort.  CoAP should be small from the outset.  

Regarding your question of not having a UDP reference, I would argue that we should recognize that this effort is explicitly for constrained devices.  As such, we should design the protocol with UDP as the transport.  These remain IP networks.  Folks that want a different performance profile can choose to run additional or alternate protocols.  We should focus on simple and lightweight protocols for constrained devices.  We should ensure that CoAP works over UDP, and we should state that it is our target transport.  Implementers, as always, can choose to run over other transports, but that should be outside of our scope.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Palmer
Sent: Monday, May 17, 2010 8:48 AM
To: core
Subject: Re: [core] Core UDP vs TCP : Redux

Hi folks

Regards - Charles Palmer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guido Moritz
Sent: 17 May 2010 16:11
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

as complex as SOAP into the stack.
I just went through the current COAP I-D and it is already quite complex! It includes many mechanisms and concepts which are also included in SOAP and other W3C/OASIS Web services specifications that I am familiar in due to my background in DPWS. 

Nevertheless, let's leave the discussion around SOAP, because there seems to be many misunderstandings related to SOAP and what I wanted to point at.
What I wanted to say is (and that is my still my opinion after reading current COAP I-D): there is no reason to bind COAP to UDP or TCP exclusively or exclude one of them. COAP seems to describe many mechanisms for interaction with resources, eventing and discovery mechanisms, mechanisms to avoid duplicated message processing etc. But all these mechanisms do not depend on the transport layer. Why should a node not support interactions by using TCP or UDP at the same time for the same resource. Of course, not the highly resource constrained one, but we are heading towards heterogeneous device infrastructures where resource richer devices in the same network might be possible as well.

Take the ideas or throw them away. But these are major decisions concerning applicability of the resulting COAP. What made HTTP and REST in the WWW such a success was that it is possible to run it over all kinds of technologies and not to restrict it to specific message sizes. Let's say there is a cool new wireless technology IEEE 802.15.XY which is capable of running 6LoWPAN but with double of the frame size and data rate at same energy costs. Will there be the next COAPXY for this new link layer because suddenly there is double the bandwidth available?

Again,
Just my two cents ;)
Guido

> > if it is reasonable to bind the CORE protocol to UDP,TCP or whatever 
> > or
if
constrained
be
SOAP

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or distribution of the material in this email is forbidden.
--------------------------------

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 17 May 2010 18:51:10 -0400

> I personally think CoAP needs to work with DTLS; if the WG moves in that direction there will be some minimum requirement for independence from the underlying protocol.

Apologies in advance if I missed it, but has DCCP been considered?

I know that it works with DTLS in theory (RFC 5238).  Further, from the 
DCCP RFC (4340):

"One DCCP design goal was to give most streaming UDP applications little 
reason not to switch to DCCP, once it is deployed.  To facilitate this, 
DCCP was designed to have as little overhead as possible, both in terms 
of the packet header size and in terms of the state and CPU overhead 
required at end hosts."

Also, assuming that TCP is not included in the final version(s) of the 
draft, would it be worthwhile to include a note in the RFC stating that 
running CoAP over TCP is not recommended?

Best,
Gilbert Clark
Grad Student

---

From: "Stuber, Michael" <[email-masked]>
Date: Mon, 17 May 2010 15:58:41 -0700

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

> I personally think CoAP needs to work with DTLS; if the WG moves in
that direction there will be some minimum requirement for independence
from the underlying protocol.

We should look at this closely.  If you examine DTLS -- and I admit I am
NOT a TLS or DTLS expert -- it appears to simply be TLS over UDP.  If I
have read it correctly, it still creates and maintains a logical
session, even if there is no session provided by the transport layer.  I
think we need to examine this closely before we choose to adopt it as
our security mechanism.

Note:  I am not saying we should be incompatible with DTLS, I am simply
saying that DTLS may not be the best choice for a native security
mechanism for CoAP.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 17 May 2010 22:05:05 -0400

DCCP provides congestion control, but no reliability, and is designed, as you quote below, for "streaming applications", such as audio and video. This seems like a poor match to the needs of this application domain.

Henning

On May 17, 2010, at 6:51 PM, Gilbert Clark wrote:

> I know that it works with DTLS in theory (RFC 5238).  Further, from the DCCP RFC (4340):
> 
> "One DCCP design goal was to give most streaming UDP applications little reason not to switch to DCCP, once it is deployed.  To facilitate this, DCCP was designed to have as little overhead as possible, both in terms of the packet header size and in terms of the state and CPU overhead required at end hosts."
> 
> Also, assuming that TCP is not included in the final version(s) of the draft, would it be worthwhile to include a note in the RFC stating that running CoAP over TCP is not recommended?
> 
> Best,
> Gilbert Clark
> Grad Student
>

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 17 May 2010 22:27:16 -0400

Point; only connection setup / teardown is reliable, so that doesn't 
really help.  That was probably not the best suggestion :)

--Gilbert

---

From: <[email-masked]>
Date: Tue, 18 May 2010 05:39:51 +0100

That quote from RFC4340 is optimistic. DCCP has not been deployed in any significant amount.

The remaining outstanding action in the DCCP WG, being debated, is to implement an efficient DCCP-over-UDP tunnel to get through NAT and firewalls and encourage DCCP adoption. Not being UDP is sufficient reason not to switch...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gilbert Clark
Sent: 17 May 2010 23:51
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Best,
Gilbert Clark
Grad Student

---

From: Robert Cragie <[email-masked]>
Date: Tue, 18 May 2010 06:42:15 +0100

Hi Michael,

I think you have to have some notion of session between a pairwise 
secure association even if it's as basic as maintaining a nonce 
associated with a shared key to ensure non-repeatability for stream ciphers.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

---

From: Robert Cragie <[email-masked]>
Date: Tue, 18 May 2010 06:49:38 +0100

Of course SOAP can be bound to almost anything as it basically uses 
whatever it is bound to as a simple transport mechanism, e.g. let's just 
use HTTP POST for everything. But that's not the point of using a 
RESTful architecture. What's more important to consider is the 
transactional model. HTTP generally has some restrictions as a 
synchronous request/response protocol and the web model has unwittingly 
made further restrictions on the client/server and threading models. 
Whatever CoAP ends up being should be less restrictive on its 
transactional model so it can potentially map to any underlying protocol.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 17/05/2010 2:58 PM, Guido Moritz wrote:
>> Von:[email-masked]  [mailto:[email-masked]]
>> An: Guido Moritz;[email-masked];[email-masked]
>> From: Guido Moritz<[email-masked]>
>> To:<[email-masked]>
>> See also SOAP over SMTPhttp://www.pocketsoap.com/specs/smtpbinding/
>>
>>> Von:[email-masked]  [mailto:[email-masked]]
>>> An: Guido Moritz;[email-masked]
>>> and decoupling HTTP from TCP would be a very good idea, as
>>>        
> implementation
>    
>> work
>>      
>>> Another example of this 'concept' is BEEP's transport profiles, for
>>>        
> which
>    
>> only
>>      
>>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of
>>>        
>> Guido
>>      
>>> Moritz
>>> Sent: 12 May 2010 14:54
>>> To:[email-masked]

>>> Sorry, but I would not agree to say 'when you are able to use TCP, you
>>>        
> are
>    
>>> size>100 Byte (without any payload). Thus the connection setup overhead
>>>        
>> is
>>      
>>> One may argue about SOAP Web services in several points, but their
>>>        
> binding
>    
>>> concept is quite nice. SOAP can be bound to which transport mechanism
>>>        
>> ever.
>>      
>>> mechanisms/protocol can be changed without an effect on application
>>>        
>> itself.
>>      
>>> Just my two cents,
>>> Guido
>>>
>>>        
>>>> Von:[email-masked]  [mailto:[email-masked]] Im Auftrag
>>>> von
>>>>          
>>> Zach
>>>        
>>>> Shelby
>>>> Cc:[email-masked]

---

From: Guido Moritz <[email-masked]>
Date: Tue, 18 May 2010 10:21:26 +0200

>From the CORE charter:
>  4) The core CoAP functionality MUST operate well over UDP and UDP MUST
>  be implemented on CoAP Devices. There may be OPTIONAL functions in
>  CoAP (e.g. delivery of larger chunks of data) which if implemented are
>  implemented over TCP. Applications which require the optional TCP
>  features will limit themselves to a narrower subset of deployment
>  cases.

Running over TCP would narrow application scenarios? It would be more than
reasonable to design COAP while keeping UDP in mind. But as long as there
are no direct dependencies of COAP itself to the transport mechanisms, don't
restrict it. This in contrast would extend application scenarios, because
you can use COAP also if reliable transport layer is required in the
scenario.

Are there dependencies to UDP or is it only because the assumed
infrastructure is highly constrained?

Guido

> Gesendet: Montag, 17. Mai 2010 18:59
> An: Charles Palmer
> Cc: core
> I personally think CoAP needs to work with DTLS; if the WG moves in that
> direction there will be some minimum requirement for independence from the
> underlying protocol.
> 
> However, what we expect from the underlying protocol has a big bearing on
CoAP
> itself.
> If we expect we can always move to TCP, there will be little need to make
CoAP
> operate on large representations with small underlying interactions.  I've
> heard a lot of pushback on assuming the availability of TCP, so far.
> 
> There is also the aspect of interoperability:  One of the great properties
of
> the Web is that everybody uses the same stack, so all Web clients and
servers
> are interoperable, with IP providing the necessary technological
diversity.
> Just standardizing CoAP without an "we expect this to run on UDP, unless
> otherwise specified" would not achieve the same level of interoperability.
> 
> <WG chair hat>In any case, designing a reliable transport as a TCP
replacement
> and then a CoAP on top of either that or TCP is very much not what the
charter
> suggests we are supposed to do.</WG chair hat>
> Instead, we should look at how stateless CoAP really can be made -- I
think
> even TFTP has too much state (and thus isn't as trivial a file transfer
> protocol as it could be).
> 
> Gruesse, Carsten
>

---

From: "Oflynn, Colin" <[email-masked]>
Date: Tue, 18 May 2010 07:23:42 -0600

> infrastructure is highly constrained?

My thoughts/feeling on the issue is that CoAP should be designed with a highly constrained environment, and as such being bound to UDP makes it a lot simpler.

The resources which CoAP accesses SHOULD be accessible another in another manner; most likely this is HTTP over TCP. Even though CoAP does not map directly to HTTP, the requests are the same and thus I don't see an issue here. Nodes which are highly constrained may only support CoAP; larger nodes can support the full HTTP method.

Of course the whole subscription/notify method might take some changes to make it accessible via HTTP... but thats another thread.

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Guido Moritz
Sent: Tue 18/05/2010 09:21
To: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

Guido

CoAP
CoAP
of
servers
diversity.
replacement
charter
think

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 May 2010 15:39:33 +0200

> The resources which CoAP accesses SHOULD be accessible another in another manner; most likely this is HTTP over TCP. Even though CoAP does not map directly to HTTP, the requests are the same and th…

That is an interesting point, as it means that our main charter item
"CoAP protocol specification with mapping to HTTP Rest API"
may need this mapping not only in a node that provides a proxy function, but also possibly right in the origin servers.  While this can be trivially reduced to co-locating the proxy with the origin server, it does provide a slightly different point of view on this mapping than I previously had.  Interesting!

Gruesse, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 18 May 2010 15:15:22 +0100

Hi Carsten,

"co-locating the proxy with the origin server" seems to be a paradox - 
can you explain what you mean? For the moment, I can't see why you'd 
need to do this.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 May 2010 16:27:20 +0200

On May 18, 2010, at 16:15, Robert Cragie wrote:

> "co-locating the proxy with the origin server" seems to be a paradox - can you explain what you mean? For the moment, I can't see why you'd need to do this.

I just mentioned this as a trivial proof that of course the CoAP-to-HTTP mapping would already specify one way to do the CoAP-to-HTTP switch on the origin server, because you could do the colocation.  But, yes, this certainly can be modeled in a simpler way.  The question is whether a client would have to care whether the HTTP access is through a (non-colocated) proxy to a CoAP-only origin server or right on the HTTP service of the origin server.  It would be nice if it didn't have to care (except maybe for the URI).  This creates some additional objectives for the HTTP mapping that I wasn't aware of.

Gruesse, Carsten

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Tue, 18 May 2010 11:01:54 -0400

Thus far, from a security perspective, the only protocol I have seen
floated is DTLS.  If end-to-end security is desired, as well as
translation from CoAP-to-HTTP and vice versa, how do we envision this
occurring?  Would the point of translation need to be a break in the
end-to-end security?

- Robby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carsten Bormann
Sent: Tuesday, May 18, 2010 10:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [core] Core UDP vs TCP : Redux

I just mentioned this as a trivial proof that of course the CoAP-to-HTTP
mapping would already specify one way to do the CoAP-to-HTTP switch on
the origin server, because you could do the colocation.  But, yes, this
certainly can be modeled in a simpler way.  The question is whether a
client would have to care whether the HTTP access is through a
(non-colocated) proxy to a CoAP-only origin server or right on the HTTP
service of the origin server.  It would be nice if it didn't have to
care (except maybe for the URI).  This creates some additional
objectives for the HTTP mapping that I wasn't aware of.

Gruesse, Carsten

---

From: "Stuber, Michael" <[email-masked]>
Date: Tue, 18 May 2010 08:27:35 -0700

If we have a deployment model in which two protocols are used, for
example CoAP with a HAN, and HTTP back to a central server, it seems we
have two obvious choices:
	(1)	Provide security within the application message contents
(i.e. not the protocol itself), such that the contents are secured
end-to-end.  An example of this would be an encrypted file.  It doesn't
matter if it is sent over FTP, HTTP, or camel train, the contents is
still encrypted and presumably only available to the sending and
receiving parties with the secret key.
	(2)	Accept a break a in the end-to-end security model at the
translation node.  The message is secured between the HAN and the
translator, and the translator and the central server, but temporarily
exposed within the translator itself as the contents are transformed
from one protocol to another.

Are there other approaches?  I could imagine some function thing where
the translator node allows a CoAP device to complete TLS negotiation
with a HTTP server, but I wouldn't want to have to write it, and the
possibility for opening a security hole seems pretty large to me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Simpson, Robby (GE Energy Services)
Sent: Tuesday, May 18, 2010 8:02 AM
To: Carsten Bormann; [email-masked]
Cc: [email-masked]
Subject: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP :
Redux)

- Robby

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

Gruesse, Carsten

---

From: Andreas Scholz <[email-masked]>
Date: Tue, 18 May 2010 18:04:26 +0200

I think Guido points out an important aspect: a resource constraint network will have to transmit and process data with fairly different characteristics

A typical way to develop an automation application is to connect services (or function blocks, etc) together to a larger application. The data exchanged between these blocks will have different characteristics. 
Assume we have a automation application with the following structure:

Process Sensor
   |           
 Logic ---- Actuator
   |
Switch

The switch will require a reliable message transport (assuming e.g. a power off functionality). Assume the process sensor produces data frequently, in this case no reliability is required because some lost packets are tolerable. The connection between the Logic and the Actuator might require reliability again. Another aspect is security. Some of those links might require secure communications, others not.

One possibility to solve these different requirements is to embed the specification of such requirements into the subscription mechanism. 
Based on these requirements different protocol bindings could be selected by COAP. If a node supports TCP and the user wants reliability, TCP is selected. If the node does not support TCP some kind of reliable UDP is selected. If no reliability is needed COAP selects pure UDP.

To support such heterogeneous scenarios, COAP might not only need the flexibility to support different bindings, but might even need the flexibility to select different bindings for individual parts of the application (unless we want to (re-)implement each of these features in or on top of the application protocol)

Coming back to the latest posts regarding security aspects: An end-to-end encryption could be one of the situations where you want to choose a specific protocol binding (e.g. SOAP + Web Service security standards, just to name a protocol suite that would support this kind of interaction).

Guido Moritz schrieb:
>>> if it is reasonable to bind the CORE protocol to UDP,TCP or whatever or
>>>       
> if
>   
>>> it is possible to leave this open and design CORE extensible and
>>>       
> flexible
>   
>>> enough.
>>>       

-- 
Andreas Scholz               Lehrstuhl Informatik III
Tel. +49 89 289-17292        TU München, Zimmer 02.11.037 FMI
[email-masked]     Boltzmannstr. 3, 85748 Garching

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 18 May 2010 12:06:44 -0400

> Date: Tue, 18 May 2010 08:27:35 -0700
> From: "Stuber, Michael" <[email-masked]>
> 
> 	(1) [...]

The exposure can be minimized by putting the translator on
the central server.  This gives you machine-to-machine
end-to-end security.  The translator can take care of
CORE<->HTTP (and possibly EXI<->XML), allowing the rest of
the central server to remain blissfully ignorant of anything
smaller than a PC or slower than 100Mb ethernet.

                                     -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 May 2010 18:30:30 +0200

> from one protocol to another.

One interesting aspect here is the trust model.
E.g., the meter may trust the utility server, and the meter may trust (maybe with a different trust model) the washing machine, but there needn't be a trust relationship between the washing machine and the utility server.  This would already make the meter a natural point to terminate (and proxy between) two separate security associations.  

Of course, not every case where you would want to locate a proxy may be so lucky.
(But I think it is very useful to discuss architecture in specific terms, not in generalizations that may or may not be relevant.)

Gruesse, Carsten

---

From: "Charles Palmer" <[email-masked]>
Date: Tue, 18 May 2010 21:45:54 +0100

Dear all

My project (http://projecthydra.info/) is exploring the use of secure
micros and smart card technology to provide tamper resistant hardware in
(for example) smart meter applications and to allow secure, dynamic
deployment of multiple applications ("value-added services" - such as
telecare) onto (say) smart meters.

The smart card industry have solved problems that are being discussed
here and elsewhere, including how to provide separate (robust) security
domains (one for each application) within a single resource constrained
micro, how to provide (robust) end-to-end secure communications channels
from one application to its off-card server through an un-trusted comms
infrastructure, and how to do secure software deployments/updates,
including updates where the application owner need not trust the card
owner.

GlobalPlatform is a key technology.

To address the last point in this thread: GlobalPlatform assumes maximum
paranoia and requires almost no trust. I would submit that in
application spaces where billions of dollars are being transferred that
is the right attitude.

We are currently playing with ideas such as:

1 How to extend a smart card architecture (normally a host-card
interface with a request initiated by a terminal and response provided
by the smart card) to an architecture where the smart card also has to
communicate with "devices" (smart meters, health-care devices).

2 How to map the GlobalPlatform capabilities onto CoRE or ZigBee SE2.0
application specifications.

We'd be very interested in exploring these areas with CoRE participants,
within this list or outside.

Regards - Charles Palmer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carsten Bormann
Sent: 18 May 2010 17:31
To: core
Subject: Re: [core] CoAP-to-HTTP and Security (was RE: Core UDP vs TCP
:Redux)

One interesting aspect here is the trust model.
E.g., the meter may trust the utility server, and the meter may trust
(maybe with a different trust model) the washing machine, but there
needn't be a trust relationship between the washing machine and the
utility server.  This would already make the meter a natural point to
terminate (and proxy between) two separate security associations.  

Of course, not every case where you would want to locate a proxy may be
so lucky.
(But I think it is very useful to discuss architecture in specific
terms, not in generalizations that may or may not be relevant.)

Gruesse, Carsten

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 May 2010 13:06:51 +0900

What about if there is a relay or proxy between the meter and the 
central server?  For example, ANSI C12.22 provides end-to-end data 
encryption.  Of course security requirements depend on the trust 
model.  Question: what is trust model of CORE?

Thanks,
Yoshihiro Ohba

---

From: Zach Shelby <[email-masked]>
Date: Mon, 24 May 2010 18:14:43 +0300

So what I heard people want here:

1. UDP as *the only* transport for simplicity and interoperability in the spec (as long as we don't reinvent TCP).
2. CoAP to be transport independent as a protocol, thus allowing it to be possibly used in other ways in the future.
3. A couple people think we might need a fragmentation feature for responses with a payload size over the maximum. 
4. DTLS might have complexity problems, should not be the only option (Michael)
5. Some transport binding framework could be explored (Robert)

I agree with 1 and 2, and my proposal would be to remove the TCP-specific text and sections from the next version of CoAP. We can make the protocol itself independent of UDP (it really already is), however UDP must be specified for interoperability reasons. I propose we anyways keep some text saying something like 

"Although this document specifies CoAP over UDP, the protocol may also be applicable over other transports such as TCP or SCTP. The specification of such use is out of scope of this document. 

This would at least give us a starting point. I don't see the need for developing frameworks or negotiation of multiple bindings for CoAP, at least not now.

Regarding fragmentation, let's not jump the gun too soon here. For the vast majority of constrained applications the 1280 byte maximum is more than enough. For cases when it is not let's first see if it would make sense to let the application deal with it. By the way, coap-01 has a mistake with the 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to use the 1280 byte maximum.

Regarding DTLS, we are specifying how to use it with CoAP as it is a secure transport. I agree with Michael that DTLS may very well be too much for many constrained devices, so we should make it clear that this is not the only way to do security, IPSEC e.g. is equally applicable (and probably simpler) but doesn't require any specification in the document. A security analysis ID would be a big help for the WG.....

Zach

-- 
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: Paul Duffy <[email-masked]>
Date: Mon, 24 May 2010 23:07:01 -0400

IMO any decision pro/con DTLS is premature.  Use of DTLS is desirable as 
it "goes with the grain" of HTTP usage patterns.

I believe the DTLS concerns revolve around how long a session can be 
kept alive.  Or alternatively, over how long a period of time can I 
amortize/cache session information for a single (expensive) key 
establishment handshake.

Yes, we need security expertise to answer this question.

On 5/24/2010 11:14 AM, Zach Shelby wrote:
>>>> How disruptive would it be to design CoRE without reference to TCP/UDP,
>>>>          
>> and
>>      
>>> (On the other hand, this has made it near impossible to swap in, say,
>>>        
>> SCTP.)
>>

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 24 May 2010 23:18:25 -0700

IMHO, 1& 2 move the document forward significantly.
For 3,  fragmentation being an exercise for the user seems okay. 

DTLS may well need more thought. 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Zach Shelby [[email-masked]]
Sent: Monday, May 24, 2010 8:14 AM
To: core
Subject: Re: [core] Core UDP vs TCP : Redux

Zach

---

From: "Oflynn, Colin" <[email-masked]>
Date: Tue, 25 May 2010 02:37:34 -0600

Hello,

I think 3 (fragmentation) should still be included in CoAP if we are proposing UDP. The main feature I'm thinking of is firmware updates which would need larger responses.

Again the fragmentation can be very simple (TFTP style), and if the user requires anything more advanced it is their responsibility. However leaving it to "users" probably means "not interpolatable", since then their is basically different responses depending on the file size.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] on behalf of Thomas Herbst
Sent: Tue 25/05/2010 07:18
To: Zach Shelby; core
Subject: Re: [core] Core UDP vs TCP : Redux

Zach

---

From: Daniel Berenguer <[email-masked]>
Date: Tue, 25 May 2010 14:32:09 +0200

Maybe I'm misunderstanding something but, is CoAP supposed to give
support for firmware upgrades? Wouldn't be easier to use proprietary
schemas over TCP or just TFTP over UDP for transferring large packet
blocks? Why overloading a M2M protocol like CoAP with such things?

I agree with Zach in that interoperability is a priority so adding a
explicit note about the recommended use of CoAP over UDP would be
useful.

Daniel.

On 25 May 2010 10:37, Oflynn, Colin <[email-masked]> wrote:
> Hello,
>
> I think 3 (fragmentation) should still be included in CoAP if we are
> proposing UDP. The main feature I'm thinking of is firmware updates which
> would need larger responses.
>
> Again the fragmentation can be very simple (TFTP style), and if the user
> requires anything more advanced it is their responsibility. However leaving
> it to "users" probably means "not interpolatable", since then their is
> basically different responses depending on the file size.
>
> Regards,
>
>   -Colin
>
>
> 2. CoAP to be transport independent as a protocol, thus allowing it to be
> possibly used in other ways in the future.
> I agree with 1 and 2, and my proposal would be to remove the TCP-specific
> text and sections from the next version of CoAP. We can make the protocol
> itself independent of UDP (it really already is), however UDP must be
> specified for interoperability reasons. I propose we anyways keep some text
> saying something like
>
> "Although this document specifies CoAP over UDP, the protocol may also be
> applicable over other transports such as TCP or SCTP. The specification of
> such use is out of scope of this document.
>
> This would at least give us a starting point. I don't see the need for
> developing frameworks or negotiation of multiple bindings for CoAP, at least
> not now.
>
> Regarding fragmentation, let's not jump the gun too soon here. For the vast
> majority of constrained applications the 1280 byte maximum is more than
> enough. For cases when it is not let's first see if it would make sense to
> let the application deal with it. By the way, coap-01 has a mistake with the
> 576B IPv4 maximum and 1280B IPv6 maximum. That doesn't work for
> CoAP(IPv4)-CoAP(IPv6) proxying. Instead we should set both to use the 1280
> byte maximum.
>
> Regarding DTLS, we are specifying how to use it with CoAP as it is a secure
> transport. I agree with Michael that DTLS may very well be too much for many
> constrained devices, so we should make it clear that this is not the only
> way to do security, IPSEC e.g. is equally applicable (and probably simpler)
> but doesn't require any specification in the document. A security analysis
> ID would be a big help for the WG.....
>
> Zach
>
>> My thoughts/feeling on the issue is that CoAP should be designed with a
>> highly constrained environment, and as such being bound to UDP makes it a
>> lot simpler.
>>
>> The resources which CoAP accesses SHOULD be accessible another in another
>> manner; most likely this is HTTP over TCP. Even though CoAP does not map
>> directly to HTTP, the requests are the same and thus I don't see an issue
>> here. Nodes which are highly constrained may only support CoAP; larger nodes
>> can support the full HTTP method.
>>
>> Of course the whole subscription/notify method might take some changes to
>> make it accessible via HTTP... but thats another thread.
>>
>>   -Colin
>>
>>

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 26 May 2010 09:41:52 +0100

I also think that fragmentation should not be part of CoAP. 
Applications that need more than 1K of data per message are likely to be 
running on devices that can support TCP/HTTP. Firmware updates can use TFTP.

I do think there would be interest in a separate effort to cover 
compressing HTTP/TCP.  If this were done, CoAP could target the very 
restricted nodes and wouldn't need to attempt to address the next size 
up, where HTTP/TCP can be used but is inefficient.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 May 2010 10:14:03 -0600

Not arguing one way or the other about what we should do with security but a few bits of information ....

Michaels email nicely highlighted that we could use what I would call an object security model where we secure the chunks of data being moved around (his option 1) or use a session security model (his option 2). Session security is often much easier to get to implemented and DTLS would be the obvious candidate for this. Object security would have advantages in a protocol that involves things like proxies, translators, caches, nodes responding on behalf of other nodes that are powered off, and multicast. 

DTLS is simply TLS stuck on top of UDP. The reliability only covers the TLS control messages but not the transported data so you still need to deal with reliability & fragmentation the same as you would do for UDP. 
 
DTLS (and TLS) support session resumption so that you only have to do expensive public key crypto the first time you ever connect to a given server and after that it can be very fast. The people doing SIP over TLS use this so that when a city looses power and all phones reboot at the same time, the servers can keep up - it's easy and works well. The client and server can decide how long to  allow the cached info to be used. 

I'm not a security expert but if we have questions we need security folks to answer, I can get the Sec ADs to find us someone to help. I don't think we are at that point yet as I suspect there is a fair amount of security expertise on this list. Let me know and I will make sure we get the needed info.  

Cullen

On May 24, 2010, at 9:07 PM, Paul Duffy wrote:

> IMO any decision pro/con DTLS is premature.  Use of DTLS is desirable as it "goes with the grain" of HTTP usage patterns.
> 
> I believe the DTLS concerns revolve around how long a session can be kept alive.  Or alternatively, over how long a period of time can I amortize/cache session information for a single (expensive) key establishment handshake.
> 

Cullen Jennings