Re: [Tsv-art] Tsvart last call review of draft-ietf-dprive-padding-policy-04

[Alexander Mayrhofer <[e-mail]>]

Magnus,

thanks for your review. I'm drafting appropriate text for the document
considering the interaction between MTU and Block Sizes. When you sad
"a small fraction of the MTU" above, i suppose you mean "a large
fraction of the MTU", because my understanding would be that
fragmentation is much more likely to occur when Block Size is set to
(e.g.)  MTU / 2  (large fraction) compared to when it was set to
(e.g.) MTU / 10 (small fraction).

I'm therefore adding

- for Maximal Length Padding:

"Depending on the negotiated size, this
strategy will commonly exceed the MTU, and then result in a consistent
number of fragments reducing delivery probability
when datagram based transport (such as UDP) is used."

- for Block Length Padding:

"The Block Size will interact with the MTU size. Especially for length
values that are a large fraction of the MTU, unless the block length
is chosen so that a multiple just fits into the MTU, Block Length
Padding may cause unneccessary fragmentation for UDP based delivery.
Also, chosing a block length larger than the MTU of course forces to
always fragment".

best,
Alex

On Wed, Apr 4, 2018 at 11:30 AM, Magnus Westerlund
<[e-mail]> wrote:
> Reviewer: Magnus Westerlund
> Review result: Ready with Issues
>
> I have reviewed this document as part of TSV-ART task to review documents with
> potential transport related issues.
>
> I note that the document in its final recommendation regarding block sizes do
> consider MTU for reasonable size choices. What I am missing in Section 4 is the
> discussion of MTU as impacting this. From my perspective, it appears reasonable
> to: In Section 4.1 consider if the Block Size will interact with the MTU.
> Especially for block sizes that are a small fraction of the MTU, unless the
> block is chosen so that a multiple just fits the MTU, the block padding may
> cause unnecessary fragmentation for UDP based delivery. Also chosing a block
> size larger than the MTU of course forces one to always fragment.
>
> In Section 4.2 I think depending on the negotiated size, the downside is that
> it will commonly result in a consistent number of fragments reducing delivery
> probability. I haven't digged into the negotiation part about maximum response
> size. But, I assume that this is not necessarily chose based on MTU
> constraints, but other limitations in the system.
>
> Note that these comments only applies for datagram based transport without its
> own fragmentation mechanism, e.g. UDP.
>
>