At Fri, 16 Jan 2015 09:27:27 +0100, Matthijs Mekking <matth...@pletterpet.nl> wrote:
> > On the draft text (also related to this higher level point): > > > > The goal of this proposal is to allow small changes to be > > communicated over UDP, and remove as much redundant information from > > the zone transfer as possible. > > > > We still need to send new RRSIGs, and since the main concern is the > > size of them (whether they are to be removed or added), I guess > > sending a non-negligible number of RRSIGs could easily require TCP, > > We would always have to send new RRSIGs, I can't really see how we could > live without? > > > even if we can omit a half of them. So I'm not sure how often we can > > avoid falling back to TCP (M)IXFR thanks to this in practice. Again, > > some actual measurement or at least a quantitative analysis may help. Apparently I was not clear about my point. Let me rephrase it: If (part of) the goal is "to allow small changes to be communicated over UDP", and if the proposed solution is to be a useful tool for that goal, then we should have the following situation: sizeof(MIXFR) <= client's UDP payload size < sizeof(IXFR) (*) (where both 'MIXFR' and 'IXFR' contain a non-negligible number of RRSIGs, and 'IXFR' would be twice as large as 'MIXFR') It's certainly true sizeof(MIXFR) is much smaller than sizeof(IXFR), but since MIXFR itself would still contain some amount of large data (i.e., new RRSIGs), I guess it may not be uncommon that sizeof(MIXFR) > client's UDP payload size. In this case, MIXFR doesn't help in terms of avoiding the fallback to TCP. On the other hand, if the size of new RRSIGs is quite small, it would also be possible that sizeof(IXFR) <= client's UDP payload size. MIXFR doesn't help in terms of avoiding the fallback to TCP in this case either. So my point is that it was not immediately clear how often we see the situation where the condition (*) holds in practice. And, hence "also related to this higher level point" (= I wonder whether there's a measurement result). I hope I'm clear enough this time. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
