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

1. Ashok Narayanan
Dave Oran
Won So
Naveen Nathan (UCI/Cisco)
Cisco

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. ! 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. ! 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. ! 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. ! 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. ! 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. ! 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. Fragment-Info ContentSize
Signature
Signature FragmentOffset
Name
Name FragmentSize
Signed-Info
Signed-Info Key (Name)
Data …
Fragment-Info
Data … Data …
Fragment-Info
… Data

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. ! 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. ! 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. ! 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.

15. ! 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

16. 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

22. ! Individualfragments should be
forwarded independent of others
! Per-hop reassembly can incur significant
delays

23. ! 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