Subject: IETF drafts FEC INFO 01, LCT BB 02, ALC PI 03, FEC BB 04

From: "Michael Luby" <[email-masked]>
Date: Thu, 18 Oct 2001 16:12:35 -0700

RMTers,
Being new to the game, I obviously didn't follow the procedure that was
meant to happen (see email below).  The last call for these 4 drafts will be
in two weeks, ending Thursday, November 1, after which we intend to submit
the drafts as Experimental RFCs.  Sorry about the confusion.
Mike

-----Original Message-----
From: Lorenzo Vicisano [mailto:[email-masked]]
Sent: Thursday, October 18, 2001 3:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: WG last call ?

Hi Mike,

my intention was to post the drafts to the list, leave
'till monday for people to comment, and if there were no
comments, post the drafts to the IETF directory and
call "last call".

doing the first 2 steps at the same time (post to the list
and to the IETF) is fine (in the worst case we will have
to resubmit). But the last call implies allowing two weeks
for people to comment before submitting as an RFC.. now
this collides with the deadline of Monday that you have specified..

could you please clarify this to the rmt list (no need
to send to internet-drafts) saying that the last-call
is 2 weeks (ending Nov 1st) after which we intend to submit
the drafts as Experimental RFC.

	thanks,
	Lorenzo

---

From: Vincent Roca <[email-masked]>
Date: Tue, 30 Oct 2001 10:47:55 +0100

Hello Mike and all,

Here are some comments for the FEC/ALC/LCT drafts.
cheers,

    vincent

------------- http://www.inrialpes.fr/planete/people/roca/
    INRIA Rhone-Alpes           Vincent ROCA
    projet Planete; B-219       [email-masked]
    ZIRST; 655 av. de l'Europe  phone: (+33) 4.76.61.52.16
    38330 MONTBONNOT - France   fax:   (+33) 4.76.61.52.52

Clarifications needed/remarks:
------------------------------

* FEC BB, section 2.1:
        Does the bullet defining the FEC Object Tx Info mean
        that the complete list of source block lengths should
        be provided ? Providing this list is only meaningful if
        they are not all of the same length.
        As I assume that they will often be of the same size, an
        alternative version where only the ``full sized source block
        length in bytes'' is provided is sufficient in most cases.

* FEC BB, section 2.2:
        Why is the source block length at most 64kbytes ?
        It seems to be an artificial limitation due to the 16 bit
        field length of the FEC payload Id.
        Luigi's RS codec can easily be used with k=64 (or more on modern
        PCs), and if the target environment is a LAN, the source can use
        let say a 1280 byte MTU. In that case the source block is larger
        than the above 64kbytes!
        It also contradicts the fact that the Encoding Symbol ID can be
        16 bit long!

* FEC BB, section 2.2: (once again ;-)
        I don't understand the rationale for having a different block
        size in a given object (except for the last block of course),
        and thus having the block size specified in the FPI rather
        than in the FTI.
        Can you add a pointer to a document (publication, RR...) that
        motivates this choice...
        May be this is related to the exact object definition...

* FEC BB, section 2.2:
        Why is the source block length ``the length in units of source
        symbols'' ? Everywhere else in this section only bytes are
        mentioned!

* FEC BB, section 2.2: (last bullet of the section)
        The wording of the source symbol bullet implicitly assumes
        that all source symbols are of the same length. If not the
        case (e.g. for the last source symbol of the block), just
        say ``the maximum length in bytes [...]''. Otherwise say it
        explicitly.

* LCT BB, section 3.2: now that the CCI HE has disappeared, the
        ``extended-size version of already existing header field'' 
        bullet should be removed.

* LCT BB, section 3.2: for the same reason, EXT_AUTH should be
        associated to value 1, not 2.

* LCT BB: I still think that defining the object service model and
        its relationship with the ALF model would be useful.
        (comments sent on Nov. 17th)

Suggestions:
------------

* LCT BB: additional HE
        In our implementation we use an additional in-band
        signalling HE that indicates the TOI of all objects of the
        current session. If we assume that the object idf (TOI)
        is used in a sequential manner, it is simply done by
        providing the first TOI and last TOI of the session once
        this information is known (i.e. when the sending application
        uses the close() function of the API). Thus, the receiving
        LCT session can easily indicate to the receiving application
        when the session is over. Of course this scheme:
        - assumes that TOIs are sequence numbers (rather than being
          the output of a hash function)
        - can be replaced by application level signalling (e.g. in
          a dedicated object or in meta-data associated with the
          objects)
        - or can be carried by an out-of-band mechanism.
        Yet I find it very convenient as it simplifies the application,
        is more dynamic than the out-of-band solution, and enables
        additional functionalities (like doing FEC decoding only when
        the appropriate number of FEC packets have been received for
        all the objects, a useful feature on a CPU limited host).

Typos:
------

* ALC PI, section 1.2: ``multi-rate'' rather than ``mult-rate''.

* LCT BB, section 3, p12: ``instantiation'' rather than ``insantiation''

* LCT BB, section 3.1, p16: ``included'' rather than ``incuded''

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

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 31 Oct 2001 17:13:22 -0800

Hi Vincent,

Thanks for your detailed comments.  Responses included below (start with
***).  I'm on vacation till Nov. 12 after this and will be off-line for the
duration.

Regards, Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 30, 2001 1:48 AM
To: Michael Luby
Cc: [email-masked]; [email-masked]
Subject: Re: IETF drafts FEC INFO 01, LCT BB 02, ALC PI 03, FEC BB 04

Hello Mike and all,

    vincent

* FEC BB, section 2.1:
        Does the bullet defining the FEC Object Tx Info mean
        that the complete list of source block lengths should
        be provided ? Providing this list is only meaningful if
        they are not all of the same length.
        As I assume that they will often be of the same size, an
        alternative version where only the ``full sized source block
        length in bytes'' is provided is sufficient in most cases.
*** No, it does not imply that the complete list need be supplied.  How this
is communicated is out of band (oob) to FEC BB, and thus for example the
source block lengths may be derived by a fixed algorithm from the object
length, it may be that they are all the same length and this is what is
passed out of band to the receiver, or they may be some complicated
algorithm shared by the sender and the receivers that is used to calculate
the source block lengths.   The only requirement is that this is
communicated oob by some means, but it doesn't at all have to be an explicit
list.  As another example, it could be that the default for an
implementation is that the full sized source block length is provided, and
then the source block lengths are derived from this based on the object
length. The point is that it is not appropriate to specify how this is
communicated in the FEC BB document, and any attempt to specify it beyond
what is already said will be too restrictive.

* FEC BB, section 2.2:
        Why is the source block length at most 64kbytes ?
        It seems to be an artificial limitation due to the 16 bit
        field length of the FEC payload Id.
        Luigi's RS codec can easily be used with k=64 (or more on modern
        PCs), and if the target environment is a LAN, the source can use
        let say a 1280 byte MTU. In that case the source block is larger
        than the above 64kbytes!
        It also contradicts the fact that the Encoding Symbol ID can be
        16 bit long!
*** This is a misreading of the subsection.  It explicitly says in this
subsection further down that the source block length is measured in units of
source block symbols, and thus the maximum source block length is 64K source
symbols, not 64KB.  There is no contradiction here, it is all consistent.

* FEC BB, section 2.2: (once again ;-)
        I don't understand the rationale for having a different block
        size in a given object (except for the last block of course),
        and thus having the block size specified in the FPI rather
        than in the FTI.
        Can you add a pointer to a document (publication, RR...) that
        motivates this choice...
        May be this is related to the exact object definition...
*** This was the desired way to do this by a variety of people.  Your
proposal to have all blocks be the same length for a given object except for
the last block is way too restrictive and inefficient for many applications
(including ours).  There is no reason to restrict it as you suggest, and
goes against how other people would use it.  If you don't want to explicitly
put the block length into the packet, you can always use the format
described in section 2.1 (and this is explicitly mentioned in the document).

* FEC BB, section 2.2:
        Why is the source block length ``the length in units of source
        symbols'' ? Everywhere else in this section only bytes are
        mentioned!
*** This was done intentionally.  The reason for this is that with this type
of FEC (which is fairly particular), the unit of a source symbol is
well-defined and the natural unit of measure, and since this communicated
in-band it makes sense to use this.  For the other FEC types, it turns out
that there are much more general notions of symbol lengths and it does not
make sense to restrict this as the unit of measure for all such FEC codes
(although for some, the symbol length is natural).  Thus, for the more
general FEC codes, the only requirement is the source block length in units
of bytes, and then if the FEC code wants to measure source blocks in units
of source symbols, it simply take the source block length in bytes and
divides by the symbol length.  In all other cases other than the FEC codes
in this section, the source block length is communicated oob, and thus the
more general measure of bytes as the source block length makes sense.

*** Lorenzo, can you figure out how to deal with this?

* LCT BB, section 3.2: now that the CCI HE has disappeared, the
        ``extended-size version of already existing header field''
        bullet should be removed.
*** Since additional header extensions may be specified by other drafts in
the future and this commment could apply to them as a guideline, I think
this sentence should be kept.  In fact, I can imagine in some future draft
an extension of the congestion control information could and very well may
be specified.

*** Makes sense.

* LCT BB: I still think that defining the object service model and
        its relationship with the ALF model would be useful.
        (comments sent on Nov. 17th)
*** I think this is too restrictive, and is part of the issue about what an
object is.  You seem to want to specify it in a particular way that does not
fit all applications, and in particular it does not fit all of the
applications I've dealt with.  I would much prefer to not have a debate
about specifically what an object is with respect to a high level document
like LCT BB, and then each application written using this general building
block can specify if required exactly what an object is for that
application.   The intent of the LCT BB document is rather broad, covering
download applications such as ALC,  but also meant to potentially cover
streaming applications, and I think it is a mistake to pin down in this
broad document exactly what an object is for each such complete protocol.

Suggestions:
------------

* LCT BB: additional HE
        In our implementation we use an additional in-band
        signalling HE that indicates the TOI of all objects of the
        current session. If we assume that the object idf (TOI)
        is used in a sequential manner, it is simply done by
        providing the first TOI and last TOI of the session once
        this information is known (i.e. when the sending application
        uses the close() function of the API). Thus, the receiving
        LCT session can easily indicate to the receiving application
        when the session is over. Of course this scheme:
        - assumes that TOIs are sequence numbers (rather than being
          the output of a hash function)
        - can be replaced by application level signalling (e.g. in
          a dedicated object or in meta-data associated with the
          objects)
        - or can be carried by an out-of-band mechanism.
        Yet I find it very convenient as it simplifies the application,
        is more dynamic than the out-of-band solution, and enables
        additional functionalities (like doing FEC decoding only when
        the appropriate number of FEC packets have been received for
        all the objects, a useful feature on a CPU limited host).
*** This seems very specific to your applications and not appropriate for a
high level building block like LCT.  In particular, there is no requirement
in LCT BB that FEC even be used.  How about you writing a specific protocol
instantiation based on LCT BB for your application, that would specify a
complete protocol with the additional header fields that you would require
that are specific to your app?

Typos:
------