Subject: Re: [core] [6tisch] How to use Uri-path option while Block option is used?

From: Thomas Watteyne <[email-masked]>
Date: Sat, 24 May 2014 12:56:39 -0700

Qin,

Correct me if I'm wrong, but you're saying that, in "Figure 7: Simple
atomic blockwise PUT" [1], since the PUT operation is atomic, the SERVER
will have to keep track of the progress of the exchange, so might as well
remember that MID=1234 corresponds to /options, and therefore not include
the Uri-path option in each transaction?

This is really a question for CORE, I'm CC'ing the CORE ML.

Thomas

[1] http://tools.ietf.org/html/draft-ietf-core-block-14#page-19

On Thu, May 22, 2014 at 11:01 PM, Qin Wang <[email-masked]> wrote:

> Hi Thomas,
>
> Please see Figure 7 and Figure 8 in
> http://tools.ietf.org/html/draft-ietf-core-block-14. They define "Simple
> atomic blockwise PUT" and "Simple stateless blockwise PUT", respectively. I
> guess in the first case, it is not necessary to include uri-path option in
> each PUT message.
>
> We really need somebody to confirm it.
>
> Thanks
>  Qin
>
>
>   On Friday, May 23, 2014 7:40 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>
>  Qin,
>
> AFAIK, the Uri-path needs to be present in each PUT message to satisfy the
> following statements from
> http://tools.ietf.org/html/draft-ietf-core-block-14:
>
> the Block options
> enable a server to be truly stateless: the server can handle each
> block transfer separately, with no need for a connection setup or
> other server-side memory of previous block transfers.
>
>
> The overriding objective is to avoid the need
> for creating conversation state at the server for block-wise GET
> requests.
>
>
> Any Block option gurus can confirm? Carsten? Zach?
>
> Thomas
>
>
> On Wed, May 7, 2014 at 6:02 PM, Qin Wang <[email-masked]> wrote:
>
> Hi All,
>
> I have a question about how to use Uri-path option if we use Block option
> to do fragmentation.
>
> Take Figure 7 in draft-ietf-core-block-14 as example.
> =============================================
> CLIENT                                                          SERVER
> |                                                                       |
> | CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
> |                                                                       |
> | <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
> |                                                                       |
> | CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
> |                                                                       |
> | <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
> |                                                                       |
> | CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
> |                                                                       |
> | <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
>
>              Figure 7: Simple atomic blockwise PUT
>
> =============================================
>
>  In my imagination, Uri-path option, which tells SERVER the resource,
> will be only in the first PUT message, i.e. CON[MID=1234], and CON
> [MID=1235], CON [MID=1235] will not include Uri-path option. Correct?
>
> Thanks
> Qin
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 24 May 2014 22:06:46 +0200

I haven’t followed the conversation, but I can confirm that all exchanges that constitute a blockwise transfer need to carry the request options that indicate what blockwise transfer this is is a part of.  So you do have to repeat the Uri-Path.

The message-ID is not useful for linking together the requests of a blockwise transfer; there is no requirement for these to be sequential (e.g., you might be interspersing a different request).  It is even possible to have multiple blockwise transfers going on from one client to one server (I wouldn’t recommend designing for that, but it might happen that way e.g. at a proxy).

I’ll try to clarify this some more in the next version of -block.

I wonder how -block has become so important for 6tisch.  Shouldn’t the 6tisch exchanges be rather short?

Grüße, Carsten

On 24 May 2014, at 21:56, Thomas Watteyne <[email-masked]> wrote:

> Qin,
> 
> Correct me if I'm wrong, but you're saying that, in "Figure 7: Simple atomic blockwise PUT" [1], since the PUT operation is atomic, the SERVER will have to keep track of the progress of the exchange, so might as well remember that MID=1234 corresponds to /options, and therefore not include the Uri-path option in each transaction?
> 
> Please see Figure 7 and Figure 8 in  http://tools.ietf.org/html/draft-ietf-core-block-14. They define "Simple atomic blockwise PUT" and "Simple stateless blockwise PUT", respectively. I guess in the first case, it is not necessary to include uri-path option in each PUT message.
> 
> On Friday, May 23, 2014 7:40 AM, Thomas Watteyne <[email-masked]> wrote:
> 
> 
> Qin,
> 
> AFAIK, the Uri-path needs to be present in each PUT message to satisfy the following statements from http://tools.ietf.org/html/draft-ietf-core-block-14:
> 
> the Block options
> I have a question about how to use Uri-path option if we use Block option to do fragmentation. 
> 
> In my imagination, Uri-path option, which tells SERVER the resource, will be only in the first PUT message, i.e. CON[MID=1234], and CON [MID=1235], CON [MID=1235] will not include Uri-path option. Correct?
> 
> Thanks
> Qin
> 
>  
> 
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 24 May 2014 13:14:57 -0700

Carsten,

Thanks for the quick reply, this is very clear. Qin, can you confirm this
answers the question you had?

The 6TiSCH WG is exploring the idea of using CoAP for neighbor-to-neighbor
communication, to enable distributed management. Ideally, the exchanges
involved are very short (and we expect the vast majority to be); in the
rare cases they're not, we were looking at Block transfer.

Thomas

On Sat, May 24, 2014 at 1:06 PM, Carsten Bormann <[email-masked]> wrote:

> I haven’t followed the conversation, but I can confirm that all exchanges
> that constitute a blockwise transfer need to carry the request options that
> indicate what blockwise transfer this is is a part of.  So you do have to
> repeat the Uri-Path.
>
> The message-ID is not useful for linking together the requests of a
> blockwise transfer; there is no requirement for these to be sequential
> (e.g., you might be interspersing a different request).  It is even
> possible to have multiple blockwise transfers going on from one client to
> one server (I wouldn’t recommend designing for that, but it might happen
> that way e.g. at a proxy).
>
> > AFAIK, the Uri-path needs to be present in each PUT message to satisfy
> the following statements from

---

From: Qin Wang <[email-masked]>
Date: Sat, 24 May 2014 18:02:04 -0700 (PDT)

Hi Carsten and Thomas,

It does answer my question. Thank you very much!

Qin

On Sunday, May 25, 2014 4:15 AM, Thomas Watteyne <[email-masked]> wrote:

Carsten,

Thanks for the quick reply, this is very clear. Qin, can you confirm this answers the question you had?

The 6TiSCH WG is exploring the idea of using CoAP for neighbor-to-neighbor communication, to enable distributed management. Ideally, the exchanges involved are very short (and we expect the vast majority to be); in the rare cases they're not, we were looking at Block transfer.

Thomas