Subject: [core] #253: Block2 vs. Initiative (Don't call us, we'll call you)

From: "core issue tracker" <[email-masked]>
Date: Mon, 05 Nov 2012 02:50:35 -0000

#253: Block2 vs. Initiative (Don't call us, we'll call you)

 In the (still unpublished) editorial rewrite, I'm trying to make one
 aspect of the behavior of Block2 more explicit than it is in the
 current draft (block-10, with some details also in Section 6 of
 observe-07).

 With Block1, it is always the initiative of the client to send the
 next block -- which is quite natural, as the client has to generate
 them and therefore knows when it's time to send the next block.

 With Block2, we support the basic case of a stateless resource on a
 server by keeping the initiative with the client as well.
 Then there are a couple of (currently less than perfectly defined)
 cases where the initiative switches to the server: Combinations of
 Block 1 and Block2 (ticket #203), and block-wise observe notifications
 (section 6 of observe-07).

 One of the objectives of block-11 is to describe the cases for
 server-side Block initiative in a more clearly defined, understandable
 way.  Up to now I thought that this is all we need to do about this.

 Klaus Hartke points out that there are other cases where
 server-side initiative may be desirable.  In particular, with buffered
 transfers (i.e., the server is setting up a cached copy of the
 resource to serve blocks from), server-side initiative is more natural.

 One design principle of CoAP is that we give the server the
 flexibility to do what best fits the application.  So, whether the
 initiative for a Block2 transfer is with the client as with Block1 or
 with the server should be decided by the server.

 If we allow that, instead of using the current rules, the client needs
 to know the outcome of the decision of the server -- otherwise, a
 request for the next block from the client would likely cross the next
 block being sent independently from the server.  This means that the
 server needs a way to say "Don't call us, we'll call you" when sending
 the first block of a block-wise response (Block2).

 Implementing this in the protocol poses a number of less important
 questions (which still need to be decided).  Let's call this
 information "the initiative bit" for know (leaving open whether that
 is realized by a separate option or by changing Block2).  Clearly, the
 default value of that bit needs to be "client-side", as we want to
 support the basic, stateless server case without any additional fluff.

 1) Do we need to make the "server-side" value explicit for the two
 cases where it already is server-side (or do we keep it implicit that
 the presence of a Block1 or Observe option in a response indicates
 server-side initiative)?  Making it explicit creates another breaking
 change and adds redundant information to a message, but may seem more
 "consistent".

 2) Does a client need a way to influence the server side decision,
 expressing a preference or even prohibiting one choice?  I don't think
 that is actually needed; the server is likely to implement only one
 way anyway.

 There may also be some work required on the potential of using
 server-side initiative for carrying out amplification attacks.  While
 amplification attacks are possible with many UDP-based protocols
 (right now, the favorite of the black-hat community appears to be
 DNS), the attractiveness of a protocol increases with the
 amplification factors achievable.  Being able to achieve amplification
 factors beyond those of DNS makes a protocol very attractive.

 (covers msg02890, #203, nits13m, nits13n)

-- 
----------------------------------+-------------------------------------
 Reporter:  cabo@…                |      Owner:  draft-ietf-core-block@…
     Type:  protocol enhancement  |     Status:  new
 Priority:  major                 |  Milestone:  post-WGLC-1
Component:  block                 |    Version:  block-10
 Severity:  Active WG Document    |   Keywords:
----------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/253>
core <http://tools.ietf.org/core/>