* [Bloat] bufferbloat vs NetSpectre
[not found] <CAA93jw6xj_-qUaeHBn-aoCKGAzG+KF0f3dCqcatYSAshUU6Mng@mail.gmail.com>
@ 2018-07-31 2:59 ` Michael Richardson
0 siblings, 0 replies; only message in thread
From: Michael Richardson @ 2018-07-31 2:59 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]
I was reading through the NetSpectre paper at:
http://misc0110.net/web/files/netspectre.pdf
I haven't finished it all yet... key thing was on page 5, which starts with:
if (x < bitstream_length)
if(bitstream[x])
flag = true
As I understand it, they are depending error packets that come back to
measure cache fills from a background of packets that fail tests such as
above.
Two things occur to me:
1) in a really badly bufferbloated network, the
super-long queues ought to completely screw things up for them.
2) fq_codel ought to something significant to the measurements.
I don't know yet if it might them better or worse. But,
it ought to do something.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2018-07-31 2:59 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAA93jw6xj_-qUaeHBn-aoCKGAzG+KF0f3dCqcatYSAshUU6Mng@mail.gmail.com>
2018-07-31 2:59 ` [Bloat] bufferbloat vs NetSpectre Michael Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox