1. Data types in P2P systems
Henning Schulzrinne
Columbia University
March 2008
IETF 71 (P2PSIP)

2. Data issues What do we store and fetch? How do we protect it?
separate topic: CMS, homebrew, ...
Analogies
file system (meta data, ACL, blob)
some had/have data types (e.g., VMS records)
hash libraries (e.g., hcreate())
database libraries (e.g., gdbm)
language features such as arrays and dictionaries
Tcl, Perl, PHP, Python, Ruby, ... ID
data
crypto wrapper
March 2008
IETF 71 (P2PSIP)

3. Requirements Need to be able to store any data item
of reasonable size
New types MUST NOT require rewriting node software
otherwise, little chance to generalize
ID (“database key”) must allow non-AOR values
otherwise, doesn’t generalize to VoD and other uses
Allow both “standard” data objects and application-specific ones
e.g., SIP registration records and vendor-specific configuration data or I-D 00 experiments
Provide access control
e.g., only creator can read
should work with semi-trusted nodes
Provide policy control per node or overlay
e.g., maximum size of objects
March 2008
IETF 71 (P2PSIP)

4. Data typing RELOAD -03: 32-bit integer with some TBD allocation scheme
e.g., similar to IANA ports registry
compromise between space efficiency and extensibility
a “usage” may define one or more data types
March 2008
IETF 71 (P2PSIP)

5. Multiple objects with same “key” (ID)
What happens if there’s a hash collision?
Possibilities
global space
{“egg”} is
may cause DOS attacks if ID = AOR
creator
e.g., ID space could be local to creator
{“egg”, alice} and {“egg”, bob} are two different objects
allows “only AOR can register AOR” policy
data type
{“egg”, 17, alice} and {“egg”, 42, alice} are two different objects
auxiliary data
{“egg”, 17, alice, label1} and {“egg”, 17, alice, label2} are two different objects
March 2008
IETF 71 (P2PSIP)

6. Access control & versioning
Basic access control policy: only owner (= creator) can replace (or delete) object
enforced by peer
can’t prevent peer from disobeying policy
Do we need more elaborate policies?
similar to Unix ACLs or chmod bits?
unbounded complexity
March 2008
IETF 71 (P2PSIP)

7. Versioning & timestamps
Do objects have timestamps?
Option 1: Just metadata
Option 2: Cannot replace newer object with older one
prevents replay attack
does not require synchronized clock in overlay
as long as all instances of owner have roughly synchronized clocks or fetch current value
March 2008
IETF 71 (P2PSIP)

8. Compound data structures
Should there be compound data structures?
Options (at least)
But also STL (see next slide)
Scripting languages (PHP, Tcl, Ruby, ...)
Need data structures AND operations
e.g., enumeration, traversal (iterator), insertion at beginning/end, ...
Interaction with policies and replication
March 2008
IETF 71 (P2PSIP)

9. Example: STL containers
Sequential
vector
fast inserts at end
list
inserts anywhere
deque
inserts start & end
Associative
multiset
duplicates allowed
set
no duplicates
multimap
1-to-many
map
1-to-1
Adapter
stack
FILO
queue
FIFO
priority_queue
sorted order
March 2008
IETF 71 (P2PSIP)

10. Example: Tcl set name(first) "Mary”
Fake two-dimensional arrays: name(a,b)
No ordering guarantees
PHP differs, for example (insertion order)
March 2008
IETF 71 (P2PSIP)

11. Proposed simple type Uniquely identified by H(data) Operations
within {“ID”, owner, type}
Operations
replace
list all {“ID”, owner, type} hashes (?)
March 2008
IETF 71 (P2PSIP)

12. Other proposals Three types: Issues that need to be resolved:
singleton
numeric array
dictionary
Issues that need to be resolved:
operations beyond single-element
replication
access control for [x] separate from data?
March 2008
IETF 71 (P2PSIP)

13. Example applications registrations voicemail TURN servers
multiple handsets for same AOR
voic
may generally use a server (announcement), not just storage
multiple writers?
but probably want to hide meta data
TURN servers
possibly indexed by some location indication
March 2008
IETF 71 (P2PSIP)

14. Summary Data model independent of DHT and protocol
But if more complicated, may need additional operations beyond store & fetch
or at least additional sub-operations (“last”)
Security issues -- what gets exposed to the (untrusted) server?
March 2008
IETF 71 (P2PSIP)