[RC5] reassigning blocks

Joe Zbiciak j-zbiciak1 at ti.com
Sat May 9 02:10:42 EDT 1998

| Please correct me if I'm wrong, but I think it means that I have to flush 
| all my checked block ASAP. And then throw away my buff-in.rc5? (Something 
| we also were requested to do near the end of the DESII contest when the 
| "reassigning" announcement was made.)

I would say no, for the following reasons:

-- 0x68 is nearly completely issued but only around 2/3rds returned.
   That means there's alot of "work in progress" that we might as well
   let finish.

-- In DES-II, they were recycling within the same 56-bit keyspace.  They
   were trying to avoid dupes between machines which grabbed a bunch of 
   blocks and sat on them and other machines which had short block latencies
   that were going to be receiving re-issued keys.

-- In DES-II there was a tight deadline.  There isn't here so some block
   latency doesn't hurt much of anything.

| Thanks to the reassiging (which I expected to happen only after the ENTIRE 
| keyspace was handed out, not just a subspace) I now have to flush to avoid 
| that blocks already checked by me but not yet flushed will be reassigned to 
| someone else.

They're reassigning out of a keyspace that was handed out quite awhile
ago.  If anyone is still sitting on 0x64 blocks, then they really need
to look at buffering alot fewer blocks.  (0x64 was last active around
the start of DES-II-1, which was Jan 13th.)

I imagine the reason for closing out subspaces is purely storage purposes.
Keeping a database of all issued/returned blocks is expensive
space-wise.  Keeping a single bit for every block in a 56-bit keyspace
requires 32MB.  And actually, you need more like at least 2 bits to
store the state of each 28-bit block.  Once a keyspace is fully closed
out, its bitmap can be completely discarded.

You shouldn't need to flush anything at this time.  Just finish and
return the blocks you've already been assigned so that 0x68 can be
closed out in a timely fashion (so we won't have to go back and start
reassigning keys from *0x68* for as long).

|  Also thanks to the LIFO processing I risk checking very "old" 
| blocks that are being handed out to some else one of these days...

Only if your buff-in is set to be larger than your buff-out, or if you
routinely do fetches/flushes before your buff-out is full.  Otherwise,
you should never have stale blocks in your buff-in.



  +------- Joseph Zbiciak ------+
  |- - - j-zbiciak1 at ti.com - - -|   without you, everything falls apart
  | -Texas Instruments, Dallas- |   without you, it's not as much fun
  |- - #include <disclaim.h> - -|   - NIN -      to pick up the pieces. 
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list