Subject: Clarifications on flow control and padding

From: Simone Bordet <[email-masked]>
Date: Thu, 12 Jun 2014 19:29:11 +0200

Hi,

draft 12, section 6.1 states that "padding is included in flow control".

A) Does this mean that, given 100 bytes of data and 300 bytes of padding:
1) the number that updates the flow control window is 400 (data + padding)
2) the number that updates the flow control window is 402 (pad_high +
pad_low + data + padding)

B) In the same example, let's assume that the stream has a remaining
flow control window of 250.
What should an implementation do ?
1) send a frame composed of: pad_low + 100 bytes of data + 149 bytes of padding
2) do not send a frame because the there is not enough window for the padding ?

C) In the same example, let's assume that the stream has a remaining
flow control window of 350.
What should an implementation do ?
1) send a frame composed of: pad_low + 100 bytes of data + 249 bytes of padding
2) send a frame composed of: pad_high + pad_low + 48 bytes of data +
300 bytes of padding

D) What if the remaining flow control window is exactly 300 (or 302 in
case A2 holds true) ?
1) send a frame composed of: pad_low + 100 bytes of data + 199 bytes of padding
2) do not send a frame because there is enough space for padding but
not for data ?

E) An application wants to write 20 MiB of data with a padding of 300 bytes.
Does this mean:
1) N data frame frames without padding, and a last frame with the
remainder of the data and 300 bytes of padding
2) N data frames each with 300 bytes of padding.

Are there security implications for case D2 (an intermediary could
stall a frame by carefully choosing window updates) and E2 (if the
padding is a constant, is its role useful) ?

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 10:44:09 -0700

> draft 12, section 6.1 states that "padding is included in flow control".

My editor's copy includes the statement:

   The entire DATA frame payload is included in flow control,
including Pad Length and Padding fields if present.

I think that's a little clearer that what is in -12.

Non-answers removed below...

Note: we're dropping pad_high in -13

Either is acceptable, provided you understand the consequences.
Though there are risks to the first, since it is likely that the
receiver will expose the fact that the data is complete by commencing
processing (and not processing the remaining padding when that
arrives).  Yes, padding is hard.

The second is the most cautious approach, but it can mean stalling.  A
safer, yet sufficiently cautious approach would be to spread padding
evenly between all frames that are sent when splitting frames, as you
do below.

See above.

I don't think that this is any different to the previous questions.

Those are very different answers.  The correct answer, is "mu".  You
need to be more precise about what "padding" means in the question.
(I would have assumed that the total amount of bytes to send is
20M+300, and not 20M+300*x for some arbitrary value of x.)