Re: Request for clarification - Flute - flag (B)

  Hi Vincent

Thanks you for this clarification, it is very clear.
It is great to have a confirmation that our solution Fast ESG is fully 
compliant to the standard

BR

Cedric



Le 20/10/2010 10:46, Vincent Roca a écrit :
> Hello Cedric,
>
> Concerning the possibility for the sender to change its mind WRT the
> B flag:
>
> - RFC 5651 says that "Once the sender sets B to 1 in one packet for a
>       particular object, the sender SHOULD set B to 1 in all subsequent
>       packets for the object until termination of transmission of
>       packets for the object."
>
> - RFC 2119 explains what "SHOULD" means in IETF documents:
>    "3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>        may exist valid reasons in particular circumstances to ignore a
>        particular item, but the full implications must be understood and
>        carefully weighed before choosing a different course."
>
> While changing B value back to 0 is not prohibited by RFC 5651,
> it is clearly recommended not doing so (several sentences insist
> on this point). An RFC compliant terminal can therefore legitimately
> consider this situation as erroneous. If a particular use case offers
> this possibility, then this should be clearly documented and the
> terminal behavior defined, but that's out of scope of IETF (at
> least for the moment).
>
> Cheers,
>
>    Vincent
>
> On 19/10/10 17:39, Cedric Thienot wrote:
>> Hi Vincent
>>
>> Thanks for this answer but let's me ask a last clarification.
>>
>>     * When B is set to 1, is it possible during these few potential
>>       additional packets that a sender changes B back to 0.
>>     * In other words, can a sender change his mind during the few
>>       additional packet and changes B value to 0 in order to keep on
>>       the transmission.
>>     * Would such server be considered as compliant?
>>
>>
>> And if the answer is positive, what should be the terminal behavior ?
>>
>>     * Restart from scratch the download,
>>     * keep on the download,
>>     * or others
>>
>>
>> Thanks again and best regards
>>
>> Cedric.
>>
>>
>> Le 19/10/2010 15:37, Vincent Roca a écrit :
>>> Hello Cedric,
>>>
>>> From RFC 5651 (LCT revised, p. 15), it is said:
>>> ---
>>> Close Object flag (B): 1 bit
>>>
>>>       Normally, B is set to 0.  The sender MAY set B to 1 when
>>>       termination of transmission of packets for an object is imminent.
>>>       If the TOI field is in use and B is set to 1, then termination of
>>>       transmission for the object identified by the TOI field is
>>>       imminent.  If the TOI field is not in use and B is set to 1, then
>>>       termination of transmission for the one object in the session
>>>       identified by out-of-band information is imminent.  B MAY be set
>>>       to 1 in just the last packet transmitted for the object, or B MAY
>>>       be set to 1 in the last few seconds that packets are transmitted
>>>       for the object.  Once the sender sets B to 1 in one packet for a
>>>       particular object, the sender SHOULD set B to 1 in all subsequent
>>>       packets for the object until termination of transmission of
>>>       packets for the object.  A received packet with B set to 1
>>>       indicates to a receiver that the sender will immediately stop
>>>       sending packets for the object.  When a receiver receives a packet
>>>       with B set to 1, then it SHOULD assume that no more packets will
>>>       be sent for the object to the session.
>>> ---
>>>
>>> There is no ambiguity IMHO. Upon receiving a packet with
>>> the B flag set, the receiver SHOULD assume that transmission
>>> of packets for this object stops, even if in practice a few
>>> additional packets MAY arrive. Specific recovery mechanisms
>>> (e.g. point-to-point recovery) can be launched at this point if
>>> needed, but that's out to scope of ALC and RMT documents...
>>> This is also the way it is implemented in our FLUTE/ALC
>>> software.
>>>
>>> Cheers,
>>>
>>>   Vincent
>>>
>>>
>>> Le 14/10/10 19:06, Cedric Thienot a écrit :
>>>> Dear flute experts,
>>>>
>>>> we would like to have your advice on the interpretation of the 
>>>> usage of the
>>>> Close Object flag (B) specified in the RFC 3450 (page 18).
>>>> On our interpretation when this flag is set to 1 by the 
>>>> transmitter, the receiver
>>>> should assume that no more packets for this object will be 
>>>> broadcasted in the future?
>>>> Therefore, the receiver can stop the reception.
>>>>
>>>>
>>>> Thanks,
>>>> Best regards
>>>>
>>>> Cedric Thienot
>>>>
>>>> www.expway.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Rmt mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/rmt
>

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt