ccnxcon2012: session 5: object sizes in named data networking
DESCRIPTION
Object Sizes in Named Data Networking Ashok Narayanan, Dave Oran, Won So (Cisco), Naveen Nathan (Cisco/UCI)TRANSCRIPT
![Page 1: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/1.jpg)
Ashok Narayanan Dave Oran
Won So Naveen Nathan (UCI/Cisco)
Cisco
![Page 2: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/2.jpg)
! 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
![Page 3: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/3.jpg)
! 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
![Page 4: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/4.jpg)
! 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
![Page 5: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/5.jpg)
! 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
![Page 6: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/6.jpg)
! 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
![Page 7: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/7.jpg)
! 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?
![Page 8: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/8.jpg)
! 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
![Page 9: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/9.jpg)
Fragment-Info
Signature
Name
Signed-Info
Data …
Fragment-Info
… Data …
Signature
Name
Signed-Info
Data
Fragment-Info
… Data
ContentSize
FragmentOffset
FragmentSize
Key (Name)
![Page 10: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/10.jpg)
! 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
![Page 11: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/11.jpg)
! 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
![Page 12: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/12.jpg)
! 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
![Page 13: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/13.jpg)
! 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.
![Page 14: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/14.jpg)
![Page 15: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/15.jpg)
! 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
![Page 16: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/16.jpg)
• 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)
![Page 17: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/17.jpg)
![Page 18: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/18.jpg)
![Page 19: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/19.jpg)
![Page 20: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/20.jpg)
![Page 21: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/21.jpg)
![Page 22: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/22.jpg)
! Individual fragments should be forwarded independent of others
! Per-hop reassembly can incur significant delays
![Page 23: CCNxCon2012: Session 5: Object Sizes in Named Data Networking](https://reader036.vdocuments.mx/reader036/viewer/2022062418/554e455ab4c905f9478b5405/html5/thumbnails/23.jpg)
! 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