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

From: Lorenzo Vicisano <[email-masked]>
Date: Tue, 16 Oct 2001 17:31:06 -0700

Vincent,

a few comments, please check inline.

	Lorenzo

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

Maybe we can just say this:

+ In some special cases an ALC source may need to produce ALC packets
+ that do not contain any payload. This may be required, for example, to
+ signal the end of a session or to convey congestion control
+ information. These data-less packets do not contain the FEC Payload ID
+ either, but only the LCT header fields. The total datagram length,
+ conveyed by outer protocol headers (e.g. the IP or UDP header),
+ enables receivers to detect the absence of the ALC payload and FEC
+ Payload ID.

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

the current specification only allows ALC on top of UDP (made clear
in the new text).
 
> 
> 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?

There is no ALC header really.. or better the ALC header borrows
its beginning from the LCT header, hence the ALC version number
is the LCT version number.. this might need to change if we define
ALC the goes directly on top of IP (now is UDP only).

---

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

Lorenzo,

> + enables receivers to detect the absence of the ALC payload and FEC

I agree that it works, but we can also say:

"The presence of the FEC payload ID is indicated by
the P flag of the LCT header."
        (and define the Payload ID present flag (P) in LCT)

which is simpler and will always work.
We can reasonably assume that any PI built on top of LCT will
need a payload ID. In the particular case of ALC, this will be
the ``FEC'' payload ID. If no FEC BB is used, this will simply
be a ``source'' payload ID.

Besides the ALC I-D says that it is recommended that the optional
additional parameter fields adhere to the Header Extension format.
Why not including them in the LCT Header Extension list instead
of creating an additional list? The fact that the LCT Codepoint
field may indicate the presence of these additional parameter
fields too is not a problem.

In other words do we really need to separate the ALC specific
fields (as done today) or just integrate them in a natural
fashion to LCT and say that their presence is required with ALC?

LCT is a very broad BB, that can be used in many many different
situations. ALC uses a subset of LCT plus some other BBs,
so make ALC really a specialized version of LCT (as said in the
ALC I-D) rather than LCT plus additional fields.

> ALC the goes directly on top of IP (now is UDP only).

I've never seen any protocol without any explicit version 
number. Today the LCT version number is a BB version number.
If it (or a part of it as I suggest) is meant to be used as a PI
version number, it should be said.

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

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 17 Oct 2001 16:06:47 -0700

> ALC I-D) rather than LCT plus additional fields.

We could use an LCT header extension to carry the FEC Payload ID
and in the new version of the draft we have reserved some of
those for this purpose. However this adds unnecessary header
overhead (4 bytes). I would not do it at this point.

> version number, it should be said.

Given that this version "0" of ALC refers to version "0"
of LCT (and not any other future LCT) we can safely say
that the LCT version number field is also the ALC version
number field.

If in the future we define a new ALC version, let's say 1, and
this refers to a different LCT version, let's say 0, then we will
have 2 options:

     1) add an ALC specific version number (this would probably
        mean prepend 4-bytes ALC specific, at least)
     2) let ALC version number override the LCT version number,
	this would have the drawback of not being able to interpret
        the LCT header out-of context, i.e. the new draft will have to say
        that when a receivers reads "1" in the version number field,
        this will mean ALC version 1 which is associated with LCT version
        0. Not really a problem.

Keeping the 2 version numbers distinct is only an issue on a protocol
instantiation that can use multiple versions of LCT.

	thanks,
	Lorenzo