prop340: Expand on why we don't allow DATA fragmentation

I was going to propose allowing DATA fragmentation, but I think I've talked myself out of it. I think it'll be useful to have a record of this line of thought for future reference.

Also happy to discuss this further or shown to be wrong :)

In particular I'm not sure how real the concern about fingerprinting / covert channels is, but figured I'd call it out as something we'd need to think through harder if want to consider changing course. For covert channels I suspect an attacker could already do just as well by choosing "weird" DATA message sizes. Likewise the fingerprinting opportunities are probably not that much worse than the general flexibility allowed in packing strategies.

requested review from @dgoulet

assigned to @jnewsome

cc @mikeperry

Thinking about this some more, maybe "issue 1" isn't so bad either.

Assuming we keep the max DATA message size the same, the worst case would ultimately be no worse than today wrt how many cells must be received before data is passed to the application.

• Today:
  • cell 1: [some other msg]
  • cell 2: DATA
• prop340 with DATA fragmentation; DATA message is incomplete until cell 2
  • cell 1: [some other msg], start of DATA
  • cell 2: rest of DATA
• prop340 without DATA fragmentation: some data can be passed to app before cell 2 is received:
  • cell 1: [some other msg], DATA msg 1
  • cell 2: DATA msg 2

So the current design without DATA fragmentation might give lower application latency. OTOH I suspect that in many cases the application wouldn't be able to do much with the "early" data anyway, since it's likely to be a partial message of some kind at the application layer.

I'm still slightly in favor of merging this, but might change my mind depending how ugly it turns out to be to try supporting creation of very specific DATA message sizes based on what we're packing it with.

and of course if we do decide to allow DATA fragmentation, an implementation would still be free to favor breaking into smaller messages instead of fragmenting.

I like this change.

Before we merge it, lets ask @mikeperry to see if he wants to add/change anything.

I am +1 on this.

IIRC, this explanation is also consistent with what @nickm has said in meetings about this.

approved this merge request

approved this merge request

merged

mentioned in commit db46703c