<div dir="ltr"><div dir="ltr"><div>Dear folks</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For on-line publishers, it could be used like the HTTP byte offset to fetch whatever byte range one is interest in.  Though I think that is mostly used to stripe request between different replicas.  Maybe combining that with routing hints would be interesting?  Though one could do pretty much the same think with segment numbers in that case.<br></blockquote><div><br></div><div>Yes, a pair of byte offset segment marker/component is equivalent to HTTP request header Range in this case.</div><div>Although, when I translated NFS into NDN, I choose to chunk every file at 4096 octets and use segment number in Data names, in order to obtain cache benefits. See <a href="https://repository.arizona.edu/handle/10150/625652">https://repository.arizona.edu/handle/10150/625652</a> section A.3.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A use case I can think of is segmenting content at non uniform chunk sizes, e.g. boundary determined by Rabin fingerprints. I had a related project although it does not directly use byte offset segmenting: Content-Addressable NDN Repository <a href="https://github.com/yoursunny/carepo" rel="noreferrer" target="_blank">https://github.com/yoursunny/carepo</a><br>
Retrieval of byte offset segmented content would require either stop-and-wait, or a manifest listing all segment boundaries to enable pipelining.<br></blockquote><div><br></div><div>Davide asked me in person on why I couldn't use segment numbers in this use case. The reason I need byte offsets in names is to enable chunking in parallel.</div><div>Rabin fingerprint works by computing a (cheap) digest in a 31-byte sliding window over file content, and declare a chunk boundary if the digest ends with several zeros. For example, using 12 zeros would cause the average chunk size to be 4096 octets. Since this process is probabilistic, the number of chunks from a given input is unknown before perform this computation.</div><div>If I want to divide a large file to multiple machines and let each machine handle a portion of the file, any machine other than the first one would not know what segment number it should use for the Data packets it generates.</div><div><br></div><div>Davide further suggested allows non-consecutive segment numbers. This solves the parallel chunking problem, but increases manifest size.</div><div>When using byte offsets in names, the manifest only needs to contain each segment's byte offset and SHA256 digest; the SHA256 digest is for eliminating duplicate segments.</div><div>When using non-consecutive segment numbers in names, the manifest also needs to contain the segment numbers. For a download to proceed efficiently, the byte offsets are still necessary, so that the downloader can seek to the correct position in the local file before writing a chunk.</div><div><br></div><div>Yours, Junxiao</div></div></div></div>