CCNxCon2012: Session 5: HTTP/CCN Gateway and Cooperative Caching Demonstrator
CCNxCon2012: Session 5: Object Sizes in Named Data Networking
-
Upload
parc-a-xerox-company -
Category
Documents
-
view
656 -
download
4
description
Transcript of CCNxCon2012: Session 5: Object Sizes in Named Data Networking
Ashok Narayanan Dave Oran
Won So Naveen Nathan (UCI/Cisco)
Cisco
! 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
! 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
! 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
! 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
! CCNx currently 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
! If CCNx 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?
! 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
Fragment-Info
Signature
Name
Signed-Info
Data …
Fragment-Info
… Data …
Signature
Name
Signed-Info
Data
Fragment-Info
… Data
ContentSize
FragmentOffset
FragmentSize
Key (Name)
! 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-host consumes reassembled object ! Cache delivers whole objects
• Physical reassembly not actually required
! 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
! 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
! 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 ! Beyond replacing IP fragmentation with CCNx
fragmentation, we are not yet ready to make a recommendation.
! 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
• 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
R1 R2 R3 R4 R5 R6
SinkSource(/src/test)
! Individual fragments should be forwarded independent of others
! Per-hop reassembly can incur significant delays
! 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