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