Subject: [Rmt] Re: IETF drafts FEC INFO 01, LCT BB 02, ALC PI 03, FEC BB 04

From: Vincent Roca <[email-masked]>
Date: Tue, 06 Nov 2001 10:44:53 +0100

Hello Mike,

A few little answers to some of your comments.
Thanks and long life to ALC/LCT !
Regards,

   vincent

> Clarifications needed/remarks:
> ------------------------------
> 
> * FEC BB, section 2.2:
>         Why is the source block length at most 64kbytes ?
>         [...]
> *** 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.

Wrong, the second sentence of section 2.2 says that "each source
block is of length at most 65536 bytes". If it is in
                           ^^^^^^^^^^^^
units of source symbol, then everything becomes consistent.

> * LCT BB: I still think that defining the object service model and
>         its relationship with the ALF model would be useful.
>         (comments sent on Oct. 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.

While I fully understand and agree with your concern about making
LCT BB as broad as possible, I still think that the following should
be clarified:
  What is the unit of data exchanged between an application and
  LCT either at a source or at a receiver?
  Is it an object or can a subset of the object be exchanged (e.g.
  at a receiver) ?
I think that an object is the natural application level framing of data.
It makes LCT an object-oriented protocol just like UDP is a datagram 
oriented protocol. For instance, a streaming application would send
a sequence of autonomous objects.
If ever you find this model too restrictive, then it must be said
explicitely in the LCT draft as this is a very important topic.
What the application puts inside the object is of course application
dependant and must not be specified in the LCT BB, I fully agree with
you.

Excuse me, the wording of the comments I sent last month was perhaps
a bit confusing...

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

This HE and another one to carry the FTI (Fec object tx info) as an
in-band HE are the only two ``non standard'' extensions we need today.
It is simple and it works. My goal was just to let you know.

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

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