On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes <[email protected]> wrote: > On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi <[email protected]> wrote: > >> >> >> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes <[email protected]> wrote: >>> >>> In any case, we should stop thinking that log delay and the MMD are >>> essential properties of this system. >>> >> >> I'm confused by this conclusion, and apologies if I've misunderstood. >> >> Can you explain how this statement differs, from say a discussion about >> keeping a database in RAM and never flushing to disk? You can have amazing >> QPS - but terrible reliability. It sounds like you're describing that >> you've built an unreliable, but efficient, system, and are using that as >> proof that reliability is not a critical property? >> > > That's part of why I used Spanner as one of our test points. At least > according to Al at the CT policy days, that's what his team is using as > storage for their logs. So presumably it's suitably reliable? > > I'm definitely willing to admit there's a trade-off here. My point is > just that the reliability requirements are not inconsistent with a > sufficiently high transaction rate to serve existing needs. >
Again, I'm confused as to how you reach that conclusion, so apologies if I'm just dense here. You've compared an extremely reliable, globally consistent storage system and established one bound (10qps) for your idea. You've then compared an extremely unreliable, globally inconsistent storage system and established another bound (60qps-200qps) I'm not sure why you've introduced the unreliable system - which has SPOF written all over it - or how it relates to this proposal. Are you suggesting that reliability is no longer necessary? Assuming reliability is necessary, and we accept 10qps for 'extremely high' reliability, and 60qps for 'extremely low reliability', doesn't your solution only provide value iff the growth rate of the ecosystem is somewhere within these bounds? Are you asserting that "10-60 qps should be enough for everyone"? I guess what I'm trying to figure out is what the consequence of this experiment is - are you proposing change? Because aren't those bounds only relevant to the specific experiment you did, which is related to your proposed solution for STH-on-every-cert? I apologize if I'm simply dense from what this implementation feedback is related to, or understanding the objective of this experiment. You suggest it may be feasible, but I see those numbers and reach the opposite conclusion, so I'm trying to understand where I'm misunderstanding.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
