Transfer length for content-encoded objects, via EXT_FTI - #90
Closed
jordijoangimenez wants to merge 1 commit into
Closed
Conversation
…file allows it
Problem
Under the MBMS Download Profile a content-encoded object could not be decoded
by any receiver. Observed live: a gzip object transmitted and received on
loopback ends "Decompressed length does not match expected Content-Length"
and the object is discarded. The FDT parser on this base already declines to
substitute Content-Length for an absent Transfer-Length once an encoding is
applied, which is correct, but nothing then supplies the real length and three
things stand in the way:
- reception was started for an object whose length the FDT never stated, so
the object was partitioned to a length that was simply not known
(src/Receiver.cpp);
- adopt_fdt_metadata() took neither Content-Encoding nor Content-Length from
the FDT entry, so an object whose reception bootstrapped from EXT_FTI was
delivered still compressed and then length-checked against the encoded size
(include/File.h);
- and the sender put EXT_FTI on the FDT packet only, gating both extensions
behind "if (toi == 0)", so the one permitted route for the transfer length
carried nothing (src/AlcPacket.cpp).
[observed, code-derived]
Basis
The profile obliges a receiver to handle these objects.
TS 26.346 V18.2.0 clause L.4.2, second list: "Content-Encoding set to 'gzip'"
is the single item of the list introduced as "may be carried in the FDT sent
by the FLUTE sender, and shall be supported by the FLUTE receiver".
It also forbids the attribute that would state the length.
TS 26.346 V18.2.0 clause L.4.4, fourth list: "The following attributes shall
not be carried in the FDT sent by the FLUTE sender:", Transfer-Length first.
And Content-Length may not stand in for it here.
RFC 3926 clause 3.4.2: "If the file is not content encoded before transport
(and thus the "Content-Encoding" attribute is not used) then the transfer
length is the length of the original file, and in this case the
"Content-Length" is also the transfer length."
That leaves the object's own EXT_FTI, which every receiver must support, and
reaching for it departs from a "should" rather than a "shall not".
TS 26.346 V18.2.0 clause L.4.7: "FEC Object Transmission Information in FLUTE
packets which carry symbols of content files should be conveyed by the
FEC-OTI parameters in the FDT". Every FEC-OTI parameter the profile permits is
still in the FDT; only the transfer length travels in band.
Raised by
a maintainer's direction that the 3GPP receive path be specification
compliant, which turned a recorded stop-and-ask into a decision
Change
The receiver defers starting an object whose length the FDT does not state,
takes it from the object's EXT_FTI when the first packet arrives, and adopts
the waiting FDT entry immediately so the object still lands at its
Content-Location and is decoded per its Content-Encoding.
adopt_fdt_metadata() now carries Content-Encoding and Content-Length across
while still leaving fec_oti to the in-band value. The sender emits EXT_FTI on
a content packet exactly when the FDT cannot state the length, which under
this profile is a content-encoded object and nothing else. Also corrects the
comment beside the sender-side prohibition, which claimed nothing is lost by
withholding Transfer-Length; that holds only for an unencoded object.
Verification
T1: EncodedObjectTransferLengthTest, 3 new cases covering the substitution
rule in both directions and an explicit Transfer-Length overriding both;
whole suite 64 cases passing.
T2: live over real multicast. A gzip object is received byte-identical,
sha256 a4366ca61727259f94ba..., the same digest as that object sent
uncompressed. The identical run discarded it before this change. An
uncompressed transfer still arrives byte-identical.
Not in this change
Emitting Transfer-Length in the FDT, which clause L.4.4 forbids.
The FDT parser's substitution rule and the decompression path itself, both of
which are already on this branch's base.
Contributor
Author
jordijoangimenez
deleted the
fix/mbms-profile-encoded-object-transfer-length
branch
August 22, 2026 13:33
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #80.
Change type: compliance fix.
A sender operating the MBMS Download Profile must not put
Transfer-Lengthin the FDT, so acontent-encoded object's transfer length is stated nowhere and the receiver had no other source for it.
Three changes give it one: reception is deferred for an object whose length the FDT does not state; the
length is taken from the object's own EXT_FTI when the first packet arrives, with the waiting FDT entry
adopted so the object still lands at its
Content-Locationand is decoded per itsContent-Encoding;and the sender emits EXT_FTI on a content packet exactly when the FDT cannot state the length.
Why EXT_FTI. Of the three routes it is the only one departing from nothing stronger than a should.
Emitting
Transfer-Lengthbreaks clause L.4.4's shall not; treating content encoding as out of profilecontradicts clause L.4.2 permitting it. Every FEC-OTI parameter the profile permits is still in the FDT.
Baseline: TS 26.346 V18.2.0 clauses L.4.2, L.4.4 and L.4.7; RFC 3926 clauses 3.4.2 and 5.
Verification. T1: 46 cases passing. T2: a gzip object received byte-identical over real multicast,
sha256
a4366ca61727259f94ba…, the same digest as that object sent uncompressed. The identical rundiscarded it before this change.