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

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