Re: AD Review: draft-ietf-rmt-flute-revised-11

Hi Rod, David and all,

A partial answer too, focusing on points b and c:

> b,c - not confident about new text, see comments and questions below
> [...]
> b) (Short version: we should revert to the original algorithm text
> plus the receiver mandated support). The algorithm is slightly
> different but does not break either old or new sender or receiver in
> either case. Note, the new "error" case really doesn't alter receiver
> behaviour, and the new algorithm allows wrapparound to a !="0" FDT
> number. However, since it is "is incremented by one for each
> subsequent FDT Instance" the probablility of x+1 (where x was the
> lowest expired instance) being also expired shortly after isn't very
> promising. Both old and new algorithms don't handle this well. Either
> the new algorithm needs additional text "after the first and
> subsequent wraparounds, subsequent new FDT instances should use the
> next higher expired FDT instance number until these are exhausted and
> then a wraparound is initiated once more" and live with the extra
> server complexity, or else we should do a reality check: 2^20-1 is a
> very big number, and any truly extreme server admins who "go for
> broke" on FDT instance IDs really ought to be responsible enough to
> configure expiry times that can handle that so that a state of
> "waiting for the next ID to timeout" won't occur. Based on this
> reality check, the initial text is more than adequate and the new text
> doesn't justify the extra complexity. However, the text "Receipt of an
> FDT Instance that reuses an FDT Instance ID value that is currently
> used by a non expired FDT Instance SHOULD be considered as an error
> case." is both harmless and useful and so should be included.

After reading your comment, I think that none of the two texts is perfect.
However we agree on the algorithm I think that can simply stated as:

int   find_fdt_instance_id_to_use()
{
    static int    id = -1; // that's an FDT instance ID, static to
                                  // remember last value used
    do {
        id++;
        if (id == 2^20) {
            id = 0; // wrapping to 0 occured!
        }
         if (FDT_instance[id] is not expired) {
            if (all_FDT_instances_are_non_expired() == true) {
                blame the administrator for using such big expiry values!
                exit(-1);
            }
            continue;   // i.e. test next id value, we know at least
                              // one value can be used
         }
         //go use this id for the current FDT Instance;
         return id;
    } while (1);
}

So that's essentially a matter of clarifying text (or inserting
a C algo). I don't think there's any change in the algorithm (no
compatibility problem) even if wording is different. But this
modification was motivated by previous AD review if I remember
well (RFC3926 has too many situations left to individual
implementations), and the fact I don't agree with sentence:
   "A new FDT Instance reusing a previous FDT
   Instance ID number, due to wraparound, may not implicitly expire the
   previous FDT Instance with the same ID."

My recommendation:
s/may not implicitly/CANNOT implicitly/


> c) Yes, and why does it do this? For the experimental we had this
> design discussion: although an FDT with all possible files is useful,
> also an FDT declaring "no new files" is useful (e.g. for recievers
> which are satisfied that they have the required files from the session
> being able to free network and local resources dedicated to a
> multicast group). Given the potential of the aforementioned number
> 2^20-1, the new definition of an FDT with Complete=true isn't always
> going to yield beautiful and compact FDTs. Besides, the complete
> "flag" might be raised when some of the older files will no longer
> have any transmitted data (e.g. for transient images for program
> guides). The old meaning of "session additions are complete" makes
> more sense to me. What do I foolishly miss in rejecting the newer
> "this is a complete file list" meaning? (BTW, I am not missing the
> skinny spec approach of MBMS to only use Complete to list all files -
> but at the time of rel6 specification this profiling was a sensible
> choice for the application cases under discussion for MBMS. Although
> skinny specs are good for the IETF too, this case doesn't seem like a
> good candidate.)

I agree with Rod that if current text suggests that an FDT Instance
with Complete set to 1 requires that all files be described, then we'll
run into problems. I think it's an non intentional side effect of a text
update that occured prior to version 06). Anyway, let's clarify it to
avoid any mis-understanding.
Good catch!

Regards,

    Vincent