Subject: [Rmt] Request for clarification - Flute - flag (B)

From: Cedric Thienot <[email-masked]>
Date: Thu, 14 Oct 2010 19:06:24 +0200

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

---

From: Vincent Roca <[email-masked]>
Date: Tue, 19 Oct 2010 15:37:00 +0200

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

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?

Thanks,

Best regards

Cedric Thienot

www.expway.com

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

---

From: Cedric Thienot <[email-masked]>
Date: Tue, 19 Oct 2010 17:39:07 +0200

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 :
>       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
>       imminent.  If the TOI field is not in use and B is set to 1, then
>       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
>       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
>> On our interpretation when this flag is set to 1 by the transmitter, 
>> the receiver

---

From: Vincent Roca <[email-masked]>
Date: Wed, 20 Oct 2010 10:46:07 +0200

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

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

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

Cedric.

Hello Cedric,

---

If the TOI field is in use and B is set to 1, then
termination of

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

for the object.  Once the sender sets B to 1 in one packet
for a

packets for the object until termination of transmission
of

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

---

software.

Cheers,

Vincent

Dear flute experts,

we would like to have your advice on the interpretation of
the usage of the

Thanks,

Best regards

Cedric Thienot

www.expway.com

---

From: Cedric Thienot <[email-masked]>
Date: Wed, 20 Oct 2010 11:32:30 +0200

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 :
> - RFC 5651 says that "Once the sender sets B to 1 in one packet for a
>    "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
> consider this situation as erroneous. If a particular use case offers

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 09:08:36 +0200

Hi Cedric

One more clarification.

The b flag semantics have been in flux and originally they did not necessarily imply immediate termination of an object transmission (just that no new data packets / FEC would be generated).  The use of should instead of must allows this still, but the new recommendation makes the preferred implementation more clear.

It is perfectly allowable for the sender to never set this to 1, however any receiver needs to know what it being set to 1 means.

On a robust channel, the b flag allows a receiver to exit a session as soon as it knows that any remaining files it is interested in aren't going to be completed in that session - and thus save power and/or attempt to get/finish reception by some other means. If the channel is lossy, even after fec, the b flag is not a reliable data source unless many file/object packets are transmitted after the flag is set. So a sender (and system designer) needs to consider the possibility of some receivers not seeing the flag set.

Cheers, Rod.

On 20 Oct 2010, at 12:32, "ext Cedric Thienot" <[email-masked]<mailto:[email-masked]>> wrote:

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

Cheers,

   Vincent

 *   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?

Cedric.

Cheers,

  Vincent

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

<http://www.expway.com>www.expway.com<http://www.expway.com>

_______________________________________________
Rmt mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/rmt>https://www.ietf.org/mailman/listinfo/rmt

<ATT00001..txt>