CCNxCon2012: Session 5: Object Sizes in Named Data Networking


Published on

Object Sizes in Named Data Networking
Ashok Narayanan, Dave Oran, Won So (Cisco), Naveen Nathan (Cisco/UCI)

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CCNxCon2012: Session 5: Object Sizes in Named Data Networking

  1. 1. Ashok Narayanan Dave Oran Won SoNaveen Nathan (UCI/Cisco) Cisco
  2. 2. !  Applications define objects of arbitrary size!  Therefore, NDN needs to be able to cache and deliver objects of arbitrary size •  The extreme case: a stream, which is infinite in size •  More realistic: a maximum object size that will serve the vast majority of common applications!  This problem needs to be solved between: •  The naming convention •  The network protocol •  The application
  3. 3. !  Natural link MTUs are small!  There’s a gap between natural MTU sizes and natural object sizes!  There are five options to bridge this gap 1.  Applications must size object to network MTU 2.  Rely on lower layer fragmentation & reassembly 3.  Naming convention to identify fragments 4.  Publisher-authored manifest to list fragments 5.  In-network fragmentation within NDN!  The truth lies in some combination of these
  4. 4. !  What are “natural object sizes”? •  Hard to tell, but some estimates exist…!  Web pages average: 16KB per page, 120KB for CSS/scripts etc!  Pictures average: 100KB per uploaded photo, 2MB per stored photo!  Video: 500KB-15MB per ABR video chunk!  Email: 75KB avg, 22KB-400KB spread!  Document per page: PDF 62KB, .DOC 25KB
  5. 5. !  Object-based formats cannot support an infinite object size •  It’s basically a question of picking a maximum object size!  It’s unreasonable for applications to size objects to the smallest possible MTU •  Applications don’t know which link the data will traverse!  Relying on underlying fragmentation is fragile •  IP fragmentation suffers from packet loss amplification & reassembly delays (3x for CCNx) •  Other lower layer transports may offer no fragmentation
  6. 6. !  CCNxcurrently relies on (2+3) – naming convention for 4KB objects, and lower layer fragmentation to carry these •  Requires fragmentation features in lower layer •  Architectural early binding to small but MTU- independent chunk size •  Imposes restrictions on naming!  Manifest-based schemes slightly better (??) •  Publisher selects private scheme for chunk naming •  Object fetch retrieves a manifest of chunk names •  Still requires MTU-independent fragment size
  7. 7. ! IfCCNx is truly to operate on any link layer, fragmentation needs to be built into the CCNx layer •  Can’t rely on lower layer to support fragmentation •  Can’t size fragments to MTU at publication! Given that the CCNx layer can fragment and reassemble, how far should it go?
  8. 8. ! Publishers sign the complete object! Any node can (re-)fragment at will! Each fragment should be completely identifiable as part of its object! Fragment cut-though forwarding without reassembly •  Critical to remove latency penalty
  9. 9. Fragment-Info ContentSize Signature Signature FragmentOffset Name Name FragmentSizeSigned-Info Signed-Info Key (Name) Data … Fragment-Info Data … Data … Fragment-Info … Data
  10. 10. ! Fragments match a pending interest •  … but don’t satisfy it! Node immediately forwards fragments towards matching PIT entry face(s)! Node keeps track of fragment set in PIT •  Consume entry once all fragments are forwarded! End-hostconsumes reassembled object! Cache delivers whole objects •  Physical reassembly not actually required
  11. 11. !  Flow balance is changed •  Significant issue for large objects •  Requires a per-hop congestion control schemes which can handle variant object sizes •  We believe an appropriate scheme exists!  Ack/Nack scheme required? •  Optional if lower layer is reliable •  Nack: Add a “subrange fetch” field to the Interest? •  Reliability can be end-to-end or hop-by-hop •  Degenerate solution: small objects, no repair
  12. 12. !  Individual fragments cannot be authenticated in the network •  Complete object can be authenticated today •  Reassemble and authenticate only at key points? •  We’re investigating whether this can be solved!  End-to-end flow control is altered •  Can deliver (a lot of) data towards a dead or uninterested client •  Depending on maximum size of object, a “cancel interest” message may be required •  We’re investigating in which cases this is needed
  13. 13. !  What runs above CCNx fragmentation? 1.  Name-based object chunking 2.  Manifest-based sub-object chunking 3.  Nothing (Application-level chunking)!  Choice of 1 vs 2 depends on palatability of naming conventions for fragmentation!  As the maximum supported object size increases, option 3 is more viable •  But this only makes sense if the aforementioned problems are brought under control •  We’ll experiment with our implementation to determine a good maximum CCNx object size, and a chunking strategy!  Beyondreplacing IP fragmentation with CCNx fragmentation, we are not yet ready to make a recommendation.
  14. 14. ! Implemented this fragmentation scheme in ccnx codebase •  Initial demo – fragmentation, reassembly, midpoint cut-through forwarding! Further investigation: •  Congestion control •  Hop-by-hop reliability •  Flow control •  Different maximum object sizes
  15. 15. R1 R2 R3 R4 R5 R6 Source Sink(/src/test)•  R1, R2, …, R6 run ccnd modified to support Link Fragmentation.•  Sink node runs: ccnget /src/test•  Source node runs: ccnput /src/test < test16KB (payload is 16000B; generates ~16KB ccnb-encoded packet)•  ccnd connect using UDP over Ethernet (1500 MTU) - Accounting for IP/UDP headers and trailing Sequence packets, UDP face MTU is 1500-20-8-9 = 1463
  16. 16. ! Individualfragments should be forwarded independent of others! Per-hop reassembly can incur significant delays
  17. 17. !  Nodes keep track of received and transmitted fragments in the PIT entry!  It is therefore possible to discover loss of fragments between nodes and re-request delivery!  Packet loss timers for hop-by-hop reliability are lower than for end-to-end reliability •  Loss timers are a multiple of maximum path RTT •  Hop-by-hop reliability timers can be 30ms where end-to-end path reliability timers are ~500ms