Opened 10 years ago

Closed 9 years ago

#253 closed protocol enhancement (fixed)

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

Reported by: cabo@… Owned by: draft-ietf-core-block@…
Priority: major Milestone: post-WGLC-1
Component: block Version: block-10
Severity: Active WG Document Keywords:
Cc:

Description

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)

Change History (2)

comment:1 Changed 9 years ago by cabo@…

Covered in -13 by removing the concept of initiative.
Observe now only notifies the first block (the client has to pick up the rest independently and correlate using the ETag), and in a Block1 transfer, the client uses requests with Block2 and non-zero NUM to gather the rest of the response.

comment:2 Changed 9 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.