Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-block-19: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 17 Apr 2016 21:48:05 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-block-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please consider whether you need to say more about UDP usage for this
extension than what the base CORE specification says - RFC 7252 has only
one mention of RFC 5405, and that only points to guidance about reducing
ACK_TIMEOUT below one second. I understand that the CoAP story includes
"most of these nodes aren't capable of generating a lot of packets in a
short timeframe", but does this extension make it easier to send multiple
UDP packets back-to-back?

I'm reading this text, 

   In most cases, all blocks being transferred for a body (except for
   the last one) will be of the same size.  

and then this text

      *  The block size implied by SZX MUST match the size of the
         payload in bytes, if the M bit is set.  (SZX does not govern
         the payload size if M is unset).  For Block2, if the request
         suggested a larger value of SZX, the next request MUST move SZX
         down to the size given in the response.  (The effect is that,
         if the server uses the smaller of (1) its preferred block size
         and (2) the block size requested, all blocks for a body use the
         same block size.)
         
and realizing that I'm confused about why all the blocks for a body might
NOT use the same block size. Maybe this doesn't matter (because an
implementation would need to be prepared for the case when all the blocks
don't use the same block size)?

The examples were helpful to me. Thank you for doing that work.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 07:27:47 +0200

Hi Spencer,

The block-wise specification does not say anything about congestion
control because it strictly layers on top of RFC 7252 and uses the
congestion control specification there (Section 4.7).  Back-to-back
packets are limited by that section (NSTART as a limit for initiating
exchanges, PROBING_RATE as a limit for sending with no response).

Block-wise transfers cannot send/solicit more traffic than a client
could be sending to the same server without the block-wise mode.

> don't use the same block size)?

The first request may be using a block size that is larger than what the
server prefers.  That is one case where the block size changes during a
whole transfer.  See also Figure 4 for an example where the client
prefers a smaller block size than the server sent initially.

So, yes, an implementation needs to be prepared for cases where at least
the initial block is of a different size than the following (full)
blocks.  I believe this is evident to the implementers at least from the
examples.

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 21 Apr 2016 08:09:43 -0500

Hi, Carsten,

> could be sending to the same server without the block-wise mode.

My problem was that I didn't understand from the text that the same method
of pacing packets that contained complete requests was being used to pace
packets that contained blocks. I think that I can derive what you're saying
from the draft, but it wasn't clear to me.

I saw that in the thread of Mirja's Discuss, you suggested adding this
point more explicitly. That would solve my issue here.

> blocks.  I believe this is evident to the implementers at least from the

That's very helpful.

Would it be correct to say (in the first paragraph I included above)
something like

    In most cases, all blocks being transferred for a body (except for
    the last one) will be of the same size. If the first request uses a
bigger
    block size than the receiver prefers, subsequent requests will use
    the preferred block size.

just so you're not relying on implementers to figure out what to implement
solely from the examples?

Thanks,

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Apr 2016 21:06:44 +0200

Hi Spencer,

I think I have addressed your comments in draft-ietf-core-block-20

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Specifically:

> My problem was that I didn't understand from the text that the same
> method of pacing packets that contained complete requests was being used
> to pace packets that contained blocks. I think that I can derive what
> you're saying from the draft, but it wasn't clear to me.
> 

See the new text in the introduction.

> just so you're not relying on implementers to figure out what to
> implement solely from the examples?

Thanks for the text suggestion.  That text is now in the last paragraph
of the introduction to section 2.

Grüße, Carsten