Re: [Rmt] FLUTE revision

[Jani Peltotalo <[e-mail]>]

Hi Mike,

You are right if there are no late-joiners and/or the first FDT Instance
is not lost.

In the revised-11 draft there is indeed better wording:

"It is RECOMMENDED that an FDT Instance that contains the file
description entry for a file is sent prior to the sending of the
described file within a file delivery session. This recommendation is
intended to minimize the amount of file data which may be received by
receivers in advance of the FDT Instance containing the entry for a file
(such data must either be speculatively buffered or discarded).  Note
that this possibility cannot be completely eliminated since the first
transmission of FDT data may be lost."

However, receiver will buffer at most that data which will be sent
between two FDT Instances and FDT Instance interval is of course an
implementation level issue. On the other hand, if the version number is
in every packet, FLUTE version 1 receiver will not buffer FLUTE version
2 packets at all.

BR,
Jani
> Hi Jani,
> 
> I guess you are thinking that the FLUTE  version 1 receivers might buffer
> data for files and then when they get the FDT that is for the new FLUTE spec
> the receivers realize that they don't support FLUTE version 2 and have to
> discard all of this data because they don't know what to do with it?  If
> that is the concern, there is advice in the FLUTE specification that
> recommends that the FDT instances should be sent before the actual data for
> the file, and that FDTs should be sent with higher reliability than the file
> data. There is stronger and clearer wording on this in the current FLUTE
> draft than in RFC 3926, but there is wording on this in the RFC 3926 as
> well, e.g.,"It is RECOMMENDED that FDT Instance that contains the file
> description entry for a file is sent prior to the sending of the described
> file within a file delivery session."
> 
> Maybe I got this wrong?
> Best, Mike
> 
> 
> On 1/26/11 1:20 AM, "Jani. Fi" <[e-mail]> wrote:
> 
>> Hi Mike&all,
>>
>> Yes, this is one possibility to signal the FLUTE version for whole FLUTE
>> session. It still have negative influence on FLUTE version 1 receivers,
>> which might buffer quite a lot unnecessary data, if the FDT Instance is
>> not received early enough.
>>
>> BR,
>> Jani
>>> Actually, looking at the FLUTE doc, it seems that the only place where the
>>> FLUTE version number is carried is in the FDT Instance header EXT_FDT, which
>>> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a
>>> FLUTE version number that MUST be set to 2.  If this is correct, then it
>>> seems fine that the version number carried in the LCT header is the ALC
>>> version number, which is 1.  Comments on this?
>>>
>>>
>>> On 1/26/11 12:33 AM, "Luby, Michael" <[e-mail]> wrote:
>>>
>>>> Thanks Jani for bringing this to our attention. We will take a look at this.
>>>> The easiest solution off the top of my head is to specify in the FLUTE draft
>>>> that the LCT version number in the LCT header MUST be interpreted as the
>>>> FLUTE version number field (just like what ALC does when it uses LCT).
>>>> However, we'll look at it more closely.
>>>> Best, Mike
>>>>
>>>>
>>>> On 1/25/11 11:02 PM, "Jani. Fi" <[e-mail]> wrote:
>>>>
>>>>> Hi Mike,
>>>>>
>>>>> Of course we can/must specify in the text as you mention below. However
>>>>> in the packet only place to signal the version number is LCT version
>>>>> number (V) field:
>>>>>
>>>>> LCT version number (V): 4 bits
>>>>>
>>>>> Indicates the LCT version number.  The LCT version number for this
>>>>> specification is 1.
>>>>>
>>>>> In RFC 5775 it is then mentioned:
>>>>>
>>>>> "The version number of ALC specified in this document is 1. The version
>>>>> number field of the LCT header MUST be interpreted as the ALC version
>>>>> number field. This version of ALC implicitly makes use of version 1 of
>>>>> the LCT building block defined in [RFC 5651]."
>>>>>
>>>>> This kind of text is missing from the experimental FLUTE RFC and from
>>>>> the revised FLUTE, but if we want to overload this field with FLUTE
>>>>> version number (as we have done in our implementation based in
>>>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1
>>>>> and 2, the packet is not anymore align with the ALC and LCT RFCs.
>>>>>
>>>>> It is also possible to leave this field for ALC/LCT version numbers and
>>>>> use for example reserved bits or LCT header extension to signal FLUTE
>>>>> version. All in all, in my opinion it is necessary to signal FLUTE
>>>>> version 2 somewhere in the FLUTE packet to be backwards compatible with
>>>>> the receivers based on the experimental FLUTE RFC.
>>>>>
>>>>> BR,
>>>>> Jani
>>>>>
>>>>>> Hi Jani,
>>>>>> I'm missing where the version of FLUTE must be the same as the version of
>>>>>> ALC and LCT. It seems that if we define this specification to be FLUTE
>>>>>> version 2, and this FLUTE specification explicitly says that it must be
>>>>>> used
>>>>>> with ALC version 1 as specified in RFC 5775 and that it must be used with
>>>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but
>>>>>> maybe
>>>>>> I'm missing something?  I think what you are saying is that there is an
>>>>>> overloaded field that carries both the FLUTE version and the ALC version
>>>>>> and
>>>>>> the LCT version?  If so, can you point to that?
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> On 1/25/11 12:51 AM, "Jani. Fi" <[e-mail]> wrote:
>>>>>>
>>>>>>> Dear RMTers,
>>>>>>>
>>>>>>> One side effect of the version number change is problem with ALC and LCT
>>>>>>> versions. Version number is signalled in the LCT header field and in
>>>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs)
>>>>>>> version number is specified to be 1.
>>>>>>>
>>>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in
>>>>>>> the same header field.
>>>>>>>
>>>>>>> BR,
>>>>>>> Jani
>>>>>>>
>>>>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce
>>>>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number
>>>>>>>> will transition from 1 to 2.  One question that has arisen: Can an FDT
>>>>>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containing
>>>>>>>> the FDT Instance ID?  I think it is and should be restricted to TOI = 0
>>>>>>>> for carrying FDT instances, but there is some ambiguities in the text
>>>>>>>> here and there that might be construed to suggest otherwise.
>>>>>>>> Mike  
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Rmt mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/rmt
>>>
>