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

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 protected]<mailto:[email protected]>> 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



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

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


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


<ATT00001..txt>

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