Subject: RE: comments on the ALC/LCT/FEC I-D

From: "Michael Luby" <[email-masked]>
Date: Tue, 16 Oct 2001 11:42:18 -0700

Thanks Justin for repsonding to one of the concerns raised by Vincent Roca.
I have the same response, i.e. that the TOI is meant to be a globally unique
identifier for the object, that will have the same value if the object is
being sourced from multiple senders, and thus it may need to be rather long
in some circumstances as Justin has outlined below.  And yes, these comments
should be sent to the list I believe (and I'm sending this one to the list).
Mike

-----Original Message-----
From: Justin Chapweske [mailto:[email-masked]]
Sent: Tuesday, October 16, 2001 10:17 AM
To: Vincent Roca
Cc: Mike Luby; Jim Gemmell; Lorenzo Vicisano; Mark Handley; Jon
Crowcroft; Luigi Rizzo
Subject: Re: comments on the ALC/LCT/FEC I-D

Is there any reason this isn't being CC'd to the mailing list?

>3- LCT: Do we really need the possibility of having a 16 byte TOI field ?
>	Probably not if its only purpose is to identify objects.
>	In our implementation the TOI is just an object identifier managed
>	in a sequential manner and starting at a predifined initial seq
>	number (just like TCP does). I guess this will be the case in most
>	implementations.
>	Besides doing 16 byte TOI to object mapping with the out-of-band
>	mechanism (as suggested) can be rather heavy!
>	Can you clarify why the TOI field can be so large in some cases.
>
We will be using a 16 byte TOI field in our implementation.  We will use
the first 16 bytes of the SHA-1 hash of the content to provide a
(somewhat) unique identifer for the content.  We are doing this because
we want to avoid any runtime negotiation of transport parameters to try
to maintain a relatively loose coupling.  This should make it easier for
us to do things like have multiple senders, under seperate
administrative control, for a single object.

Thanks,

--
Justin Chapweske, Onion Networks
http://onionnetworks.com/

---

From: Vincent Roca <[email-masked]>
Date: Wed, 17 Oct 2001 10:30:24 +0200

Michael Luby wrote:
> And yes, these comments

You're right Mike.
Here is a copy of the comments I sent directly to the I-D
authors yesterday for those who may be interested.
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

----------------------------------------------------------
                  some comments on the
        LCT draft, draft-ietf-rmt-bb-lct-01.txt, July 2001
        ALC draft, draft-ietf-rmt-pi-alc-02.txt, July 2001
        FEC draft, draft-ietf-rmt-bb-fec-03.txt, July 2001

           vincent roca - October 16th, 2001
----------------------------------------------------------

Serious problem:
----------------

1- ALC draft: it is assumed that the FPI field is always present.
        This is a problem if the source wants to send a ``signaling only''
        packet, e.g. to close the session.
        Don't forget that this close session packet may be sent in
situations
        where the session must be immediately released, no matter whether
        there remains packets to be sent or not.
        I suggest to add a bit in the LCT header to indicate wether the
        FPI field is present or not.
        Another advantage of doing that is that ALC would really be a
        ``specialized version of an LCT packet'' rather than being an LCT
        header plus a FPI field (and possibly other optional fields).

Clarifications needed:
----------------------

2- LCT: does the HDR_LEN field include the fixed size LCT header and fixed
CCI?
        That was not the case in previous LCT versions, it seems to be
        the case now but this is not clearly said (e.g. is CCI part of
        the LCT packet header?).

4- ALC draft, section 3.2:
        it is said that the ``FEC encoding flag'' may be communicated
        via the value of the LCT codepoint field.
        As Justin mentionned, the FEC BB draft says that a one bit
        ``FEC encoding flag'' may be included in the FPI. So there are two
        possibilities of indicating wether this is a source symbol or
        FEC symbol. Can you choose one (nice for interoperability
purposes).
        I suggest the one bit flag in the FPI...

5- FEC BB: Can you justify the Small Block Systematic FEC formats.
        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 following remark (object
definition).

What is an object?
------------------

6- I'd like to see somewhere a discussion on a possible LCT/ALC service
   model.  More specifically what is an object?

        The LCT draft, page 6 (General Archi), introduces several
examples.
        The TV channel example puzzles me. It is suggested
        that objects could correspond to individual programs like a movie.
        Implicitely it is suggested that this is a streaming session.
        This is where I don't agree!

        For me an object is an Application Data Unit (ADU) in the
        ALF (Application Level Framing) sense. Therefore the object is
        the unit of data exchanged between the applications and the
ALC/LCT
        protocols. For streaming sessions, each object could correspond to
        individual movie frames, but not to the whole movie.
        Said differently, IMHO a ``streaming object'' is a non-sense.

        I admit that we can make other hypotheses, i.e. assume that
        accesses to individual blocks is possible at a receiver, but
        I don't think that it would be a good choice.

Nice to have / suggestions:
---------------------------

7- LCT: add the DemuxLabel flag introduced in previous LCT draft.
        This demux label can be usefull in case LCT is used directly
        on top of IP rather than UDP as there would be no UDP port number.
        This demux label can also be usefull to easily avoid LCT session
        collisions.
        This DemuxLabel can be carried in a dedicated Header Extension so
        that there is no additional cost for the common case (LCT/UDP/IP).

8- ALC: there is no ALC version number. This may be a problem...
        Maybe some bits of the LCT version number could be used for that?

Minor remarks:
--------------

9- LCT: Update the [3] reference on FCAST. Published in IEEE Network,
2000.
        (easier to find than an internal RR)