Re: [DNSOP] Consensus suggestion for EDE and the TC bit

[Ben Schwartz <[e-mail]>]

I think we are talking about performance in a situation that (a) is so
pathological that it will almost never happen and (b) at worst, will only
slow down failure, not success.  For that reason, I would avoid introducing
any additional protocol complexity in pursuit of optimization.  I think our
simplest and most appealing option would be to treat EDE exactly like any
existing EDNS Option (i.e. set the TC bit).

To be clear, we are talking only about the case where a response "fits"
until the EDE is added, after which it exceeds the limit and is truncated.
If optimizing this situation is important, I would suggest adding a
requirement to the EDE draft that EDE be the last option in OPT.  Then as a
client, I can easily detect this situation, because the truncation point is
in the middle of the EDE option.  The client logic then is very simple: if
I don't care about EDE, I can ignore the TC bit.

On Thu, Nov 21, 2019 at 2:53 PM Wes Hardaker <[e-mail]> wrote:

>
> During the first DNSOP meeting at IETF 106 there was a discussion that
> had multiple opinions about what to do with setting the TC bit for EDE
> information, which is generally supplemental.  During my presentation I
> mentioned that an associate of Viktor suggested creating a new bit, and
> during the conversation there was discrepancy about whether or not that
> was a good idea.  Brian Dickson then proposed that the new bit only
> modify future clients that wanted to use it, thus leaving the EDE spec
> setting the TC bit.  A future bit could be defined that would indicate
> that only supplemental information was dropped.
>
> My proposal for EDE is that we follow this train of thought, which seems
> to be the widest idea accepted from what I could tell.  TLDR for things
> to do:
>
> 1. We have the EDE document say to set the TC bit (which it already did)
> 2. We create a new document that defines an extra bit for indicating
>    that the dropped information was supplemental and didn't contain
>    operationally important information.
>
> If this sounds like a good compromise, great!  If you would like to
> propose an alternative, great!  do so!
>
> In the mean time, I threw together a quick ID for the new bit as well:
>
> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-drop/
>
> --
> Wes Hardaker
> USC/ISI
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>