Subject: [core] Why BLOCK option and not simply TFTP?

From: Paul Duffy <[email-masked]>
Date: Tue, 10 May 2011 22:32:11 -0400

Zach / Carsten,

Much appreciated if you could enlighten me re: the subject question.

Feel free to point me to a prior thread.  I have searched the mailer, 
can't seem to locate the reasoning.

Cheers

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 May 2011 10:17:07 +0200

Yep, comes up repeatedly.

There are a couple of reasons:

1) TFTP is trying to solve a different problem (file transfer vs. resource access).
   CoAP is providing access to resources, and it is useful not to have an artificial upper limit to the size of their representations, as well as have a way to avoid adaptation layer fragmentation if desired.

2) TFTP is more complex and requires more state than CoAP, so I have no idea where the "simply" comes from (unless you already had to implement it for some other reason -- then of course just using that implementation is "simple").

For more details, Google gives you e.g. these threads:

http://www.ietf.org/mail-archive/web/core/current/msg00065.html
http://www.ietf.org/mail-archive/web/core/current/msg00141.html
http://www.ietf.org/mail-archive/web/core/current/msg00986.html
http://www.ietf.org/mail-archive/web/core/current/msg01887.html

There are links "Thread next" in the mailman archive interface, so you can follow the thread and find the messages that discuss TFTP specifically.

BTW, if you are looking for discussions on any subject in the mailing list, Google allows you to search within a site, e.g.:

http://www.google.com/search?q=tftp+site%3Ahttp%3A%2F%2Fwww.ietf.org%2Fmail-archive%2Fweb%2Fcore

Also, there are only about 2000 messages in the mailing list, so if you want to become familiar with CoAP, simply scanning them is indeed a viable option.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Wed, 11 May 2011 05:44:16 -0500

Perhaps the reason he couldn't find them with a search is that the reasons
were never given before, at least not so clearly.  Thanks for answering
this.

On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann <[email-masked]> wrote:

>   CoAP is providing access to resources, and it is useful not to have an
> artificial upper limit to the size of their representations, as well as have
> a way to avoid adaptation layer fragmentation if desired.
>

Where does tftp artificially limit the size of the representations it could
transfer?  In what way is its block fragmentation solution architecturally
different from CoAP's?

> 2) TFTP is more complex and requires more state than CoAP, so I have no
> idea where the "simply" comes from (unless you already had to implement it
> for some other reason -- then of course just using that implementation is
> "simple").
>

I'm really not seeing this.  You yourself complained that the latest base
CoAP draft was 80 pages for a  "protocol you could implement in an
afternoon" (a claim I view with extreme doubt).  RFCs 1350, 2347, and 2349
combined are 22 pages, just less than the 23 for CoAP Block which requires a
CoAP implementation behind it to work.

Plus, 20 years proven success at its function?  IMO, it's a shame TFTP
wasn't considered more seriously for CoAP's large-representation transfer
needs.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Wed, 11 May 2011 14:05:01 +0300

On May 11, 2011, at 1:44 PM, Peter Bigot wrote:

> Perhaps the reason he couldn't find them with a search is that the reasons were never given before, at least not so clearly.  Thanks for answering this.
> 
> Where does tftp artificially limit the size of the representations it could transfer?  In what way is its block fragmentation solution architecturally different from CoAP's?

That wasn't the point. The reason why CoAP provides an (optional) block transfer mode is not to have an artificial upper limit (1024 bytes) to the size of CoAP representations. In 6LoWPAN networks it is even more important to keep the block size smaller for performance reasons. This is also important when proxying to/from HTTP where there are no such limits. 

I find the TFTP conversation to be a bit silly. Why doesn't everyone on the web use FTP for access resources and implementing REST interfaces? 

> I'm really not seeing this.  You yourself complained that the latest base CoAP draft was 80 pages for a  "protocol you could implement in an afternoon" (a claim I view with extreme doubt).  RFCs 1350, 2347, and 2349 combined are 22 pages, just less than the 23 for CoAP Block which requires a CoAP implementation behind it to work.

The length of the document has little to do with its complexity. There is a ton of explanatory, tutorial and IANA etc. related information that makes what we are doing in CoRE easier to learn for people. Anyways, it doesn't matter as these are two different protocols.

> Plus, 20 years proven success at its function?  IMO, it's a shame TFTP wasn't considered more seriously for CoAP's large-representation transfer needs.

Wait a second.  TFTP and CoAP are separate protocols, and for different purposes. If you want to transfer large *files* then I recommend that you (you have to make that decision) go ahead and use TFTP. But TFTP helps no more to realize resource manipulation than FTP does. 

This is really a system design issue in the end. You may very well use core-coap for resource access on a device, and then invoke TFTP (or whatever) for transferring e.g. a large firmware. They are not in any way mutually exclusive. 

Zach 

> 
> Peter
> _______________________________________________
> 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: Peter Bigot <[email-masked]>
Date: Wed, 11 May 2011 06:50:39 -0500

I don't want to keep rehashing things that I've failed to communicate
multiple times, so one last perspective:

The suite of Internet protocols has been a runaway success because the
architecture encourages use of specific protocols for specific tasks that
are as simple as the task allows.  CoAP appears to be intended to provide an
application layer for interoperable REST communications over a datagram
transport.  I can see no reason why it should be obliged to also supply a
solution for transferring data that is larger than a datagram, when there
are existing protocols that accommodate that need.

Transferring a representation by reference (e.g.,
tftp://server/path/to/resource) is a perfectly sensible approach that allows
adaptation and specialization, and is used by HTTP-based systems where
appropriate (e.g., rtsp).  From previous discussions the sense of the
working group was that CoAP will not support redirection to other
protocols.  If this has not changed, I believe it to be a fundamental
architectural mistake.  If it has changed, TFTP is a viable alternative to
CoAP Block for systems where the resource representation can exceed the
datagram size.

Peter

On Wed, May 11, 2011 at 6:05 AM, Zach Shelby <[email-masked]> wrote:

> > Perhaps the reason he couldn't find them with a search is that the
> reasons were never given before, at least not so clearly.  Thanks for
> answering this.
> >
> > Where does tftp artificially limit the size of the representations it
> could transfer?  In what way is its block fragmentation solution
> architecturally different from CoAP's?
>
> That wasn't the point. The reason why CoAP provides an (optional) block
> transfer mode is not to have an artificial upper limit (1024 bytes) to the
> size of CoAP representations. In 6LoWPAN networks it is even more important
> to keep the block size smaller for performance reasons. This is also
> important when proxying to/from HTTP where there are no such limits.
>
> I find the TFTP conversation to be a bit silly. Why doesn't everyone on the
> web use FTP for access resources and implementing REST interfaces?
>
> The length of the document has little to do with its complexity. There is a
> ton of explanatory, tutorial and IANA etc. related information that makes
> what we are doing in CoRE easier to learn for people. Anyways, it doesn't
> matter as these are two different protocols.
>
> Wait a second.  TFTP and CoAP are separate protocols, and for different
> purposes. If you want to transfer large *files* then I recommend that you
> (you have to make that decision) go ahead and use TFTP. But TFTP helps no
> more to realize resource manipulation than FTP does.
>
> This is really a system design issue in the end. You may very well use
> core-coap for resource access on a device, and then invoke TFTP (or
> whatever) for transferring e.g. a large firmware. They are not in any way
> mutually exclusive.
>
> Zach
>
> >
> > Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 May 2011 16:09:43 +0200

Yes, the Web architecture has URIs to enable match-and-pick between multiple protocols.

However, match-and-pick should not turn into a game of Tetris.

Trying to build a larger system out of one protocol that is about manipulating resources, but cannot manipulate large objects (i.e., CoAP without Block), with another that can handle large objects but only can do stateful file transfer and no other methods, just creates pain.
(Imagine a Web where you can't use HTTP for anything larger than, say, 64 KiB, and need to use FTP instead.  Imagine running SOAP over FTP once you hit 64 KiB...)

So, having Block in CoAP is a good thing, independent of whether TFTP has good applications in your system design or not.

As of today, we haven't put any redirect function into CoAP at all.
If and when we do, we'll certainly have to look at use cases and make sure we cover what we need.
(Note that you can always carry any kind of URI in your payload.
The one place where we do carry long-form URIs in a CoAP option, Uri-Proxy, certainly does support tftp:// URIs, if you need them.)

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Wed, 11 May 2011 13:38:31 -0400

Thanks Carsten,

This was the same info I'd previously read ;)

At first glance, COAP BLOCK option smells an awful lot like a TFTP 
implementation.

- I don't see TFTP being any more or less stateful that COAP.
- I don't see any difference between a "resource" and "file" 
designation.  They are all resources.
- TFTP does provide the Blocksize option to control fragmentation.

That said, what does appear compelling about the BLOCK option ...

- all the RESTful methods are available via COAP versus just read/write 
of TFTP.  I can delete a large resource using COAP, I can't do that via 
TFTP.
- Using BLOCK, whatever COAP security mechanisms are in place can be 
applied to the resource transfer.

Cheers

On 5/11/2011 6:44 AM, Peter Bigot wrote:
> On Wed, May 11, 2011 at 3:17 AM, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>       CoAP is providing access to resources, and it is useful not to
>     have an artificial upper limit to the size of their
>     representations, as well as have a way to avoid adaptation layer
>     fragmentation if desired.
>
>
>     2) TFTP is more complex and requires more state than CoAP, so I
>     have no idea where the "simply" comes from (unless you already had
>     to implement it for some other reason -- then of course just using
>     that implementation is "simple").
>
>
> I'm really not seeing this.  You yourself complained that the latest 
> base CoAP draft was 80 pages for a  "protocol you could implement in 
> an afternoon" (a claim I view with extreme doubt).  RFCs 1350, 2347, 
> and 2349 combined are 22 pages, just less than the 23 for CoAP Block 
> which requires a CoAP implementation behind it to work.
>
> wasn't considered more seriously for CoAP's large-representation 
> transfer needs.
>
> Peter