Subject: [core] draft-ietf-core-block-08 - Sessions

From: Klaus Hartke <[email-masked]>
Date: Wed, 11 Apr 2012 20:30:38 +0200

-block has the concept of a session, i.e. the first request of a
blockwise transfer creates a context at the server in which further
requests from the client are processed. A server MAY not actually have
to implement this if it can satisfy all requests without this context,
but it seems that a client MUST assume that a server creates one.

What are the rules for matching an incoming request to a session?

Can a client have multiple up/download sessions with the same resource
at the same time?

When does a session end? What happens if a client creates a session
but never sends/retrieves the last block?

Should the duration for which the server is willing to keep the
session open before it times out be communicated to the client?

Should the client be able to request a minimum duration for which the
server should keep the session open? Use case: the client needs a
significant amount of time to process a downloaded block/construct the
next block to upload/obtain the next block from a downstream client;
it would be bad if the server timed out the session halfway through.

Should the client have the ability to cancel a session?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Apr 2012 23:20:21 +0200

On Apr 11, 2012, at 20:30, Klaus Hartke wrote:

> -block has the concept of a session,

I don't think so.  At least, I don't find that word in -block-08.

> i.e. the first request of a

There is a concept called atomic processing (for Block1).
I think we just discussed that the text for this needs improvement.

For Block2, there is text that says:

   If the ETag Options do not match in a GET transfer, the
   requester has the option of attempting to retrieve fresh values for
   the blocks it retrieved first.  To minimize the resulting
   inefficiency, the server MAY cache the current value of a
   representation for an ongoing sequence of requests.  The client MAY
   facilitate identifying the sequence by using the Token Option with a
   non-default value.  Note well that this specification makes no
   requirement for the server to establish any state; however, servers
   that offer quickly changing resources may thereby make it impossible
   for a client to ever retrieve a consistent set of blocks.

I think you are conflating the two mechanisms and calling both session.

> What are the rules for matching an incoming request to a session?

For atomic processing of Block1, the current text of the rule is:

   In this case, when reassembling the representation from
   the blocks being exchanged to enable atomic processing, the
   reassembler MUST compare any Token Options present (and, as usual,
   taking an absent Token Option to default to the empty Token).  If
   atomic processing is not desired, there is no need to process the
   Token Option (but it is still returned in the response as usual).

For Block2, any such cache mechanism is indexed by the Token, see above.

> Can a client have multiple up/download sessions with the same resource

That is the point of the above language for Block1.

Maybe it can be questioned whether for Block1 that isn't a bit of a fringe case.
A better rule might be simply not to allow multiple Block1 sequences to the same resource in parallel.

Similarly, a server might simply remember a single cached value for an endpoint for Block2 access to a rapidly changing resource.

For Block1, having multiple atomic PUTs going on in parallel from one endpoint is not very useful.
A point could be made that this is more useful with POST.

> but never sends/retrieves the last block?

The server will have to give up on the state at some point.
This is easy for the Block2 cache.  
For atomic Block1, giving up the assembled state is a bit more heavyweight. 

> session open before it times out be communicated to the client?

Being able to do this is probably a good idea.  I think we should discuss this in the general context of the Patience/Pledge proposals.

> it would be bad if the server timed out the session halfway through.

Ditto.

> Should the client have the ability to cancel a session?

Good point.  I'm not quite sure of the use case, but it would be "nice" for a client to be able to indicate to the server that it does not intend to make any further use of any state assembled (Block1)/cached (Block2).  (However, note that we have no other mechanism in place to "cancel" any other kind of cache entry.)  Closing a DTLS connection obviously is one such indication, but may be a bit heavyweight (and doesn't work for NoSec).

Grüße, Carsten