Subject: [Rmt] File delivery for ALC -- draft-paila-rmt-fdalc-00.txt

From: [email-masked]
Date: Wed, 12 Feb 2003 18:37:22 +0200

Hi all,

I have submitted an Internet-Draft that specifies a way to use ALC for file delivery.
In the RMT WG session of IETF-56 we will discuss the document.

Regards,
 Toni

> A New Internet-Draft is available from the on-line Internet-Drafts directories. 
>
>
>       Title       : FDALC - File Delivery for ALC 
>       Author(s)   : T. Paila 
>       Filename    : draft-paila-rmt-fdalc-00.txt 
>       Pages       : 21 
>       Date        : 2003-2-10 
>
> This document defines unidirectional delivery of files. The 
> specification builds on Asynchronous Layered Coding, the base 
> protocol designed for massively scalable multicast distribution. 
> Thus, this document specifies a technique called FDALC - a mechanism 
> for signalling and mapping the properties of files to concepts of ALC 
> in a way that allows receivers to assign those parameters for 
> received objects. 
>
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-paila-rmt-fdalc-00.txt

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

---

From: Vincent Roca <[email-masked]>
Date: Thu, 13 Feb 2003 10:30:55 +0100

Hello Toni,

A few comments on draft-paila-rmt-fdalc-00.txt...

File distribution is for sure the main use of ALC/LCT, and having
guidelines explaining how to do that is useful. Yet there are
several points on which I disagree.

** Your proposal is to keep file meta data (contained in the FDT object)
separate from file objects. Doing that you create inter object
dependencies: the receiving application cannot do anything with a file
object until it has also received the associated FDT object.
This is a source of inefficiencies (eg the file object can be rather
large and require a large amount of RAM) and leads to useless delivery
order assumptions (section 4).
You can have a look at the famous Clark/Tennenhouse sigcomm90 paper on
ALF for more background on why this is the wrong way of doing things.

** A file distribution over ALC scheme was already discussed in an
early version (obsoleted of course) of ALC/LCT,
draft-ietf-rmt-pi-alc-01.txt,
in annex 1 (A File Transfer using ALC - 'Fcast').
You can retrieve it at URL:

http://www.inrialpes.fr/planete/people/roca/mcl/doc/draft-ietf-rmt-pi-alc-01.txt

We implemented it and have used it for more than 2 years now, under
many different situations/assumptions without any problem.

The approach is totally different from FDALC since file meta data
are appended to the file content, and everything is submitted as a
SINGLE ALC object. There is no inter-object dependencies and objects
can be received in any order.

The only limitation is that the number of objects in a session and
the TOI of these objects are not specified with this approach (whereas 
these two informations are part of the FDT table in FDALC).
In our implementation we bypass this problem by using sequential TOIs
and adding a private header extension (PI specific extension of HET>63)
indicating the number of TOIs in a session once this is known (ie. at
session start if the sender must distribute a fixed number of files, or
during the session if objects are produced dynamically).
Of course this information can also be carried out of band (eg. in the SDP
announcement) if this is known in advance.

** Requiring (or even recommending) that a single channel (layer) is
used per ALC session (section 4) prevents the use of layered congestion
control protocol and therefore the use of FDALC on the Internet...
Even if this appropriate for closed non-Internet networks, it would be a
pity to define a file delivery standard that cannot be used for the
Internet.

The remaining is for non critical remarks:

** Don't require that object be files; managing file slices within
a file distribution session brings many benefits, especially when
small block FEC codes are used (see our INRIA RR #4411 or the ISCC'02
paper).

** The use of SDP for session description is fine. Yet I would add
(even if it is not always used) several additional information as
mentioned in the LCT RFC:
 - congestion control protocol (this is a MUST!)
 - authentication scheme if used
(something else ???)

** You say in section 3.2 that "delivery of a previous FDT MUST end
before the delivery of the next FDT starts."
What about delayed packets arriving several seconds after their
transmission? Even if not common, it may happen.

** I have the feeling that you often assume a sequential delivery of
packets on the channel(s). If ALC/LCT does not specify anything on the
packet transmission order, in practice (at least in our implementation, I
don't know for others) transmissions take place in a more or less random
order (once again see INRIA RR #4411/ISCC'02 for the motivations behind
it: congestion control, on-demand delivery, robustness...).

** Why should FDT version be limited to 65535 max ?
Usually this is the kind of limitation we have with binary 16bit fields,
but in case of FDALC this information is carried in a textual field
and it makes no sense to have such a strict limitation. A limitation
of 2^32-1 seems better.

** section 3.2, it is said that "a rx may use an FDT after its expiration
time if..."! Why do you define expiration times it they are not used
in certain cases ?

** section 3.2, it is said: "... or drop it [TOI 3 in the FDT]. In the
latter case the interpretation should be that the file has already been
delivered."
Am I right if I replace "delivered" by "the source will not send any
further packet for object TOI=3" ?
In that case another way of doing it is to use the Close Object flag (B)
of LCT.

Hope it will help. And feel free to continue this discussion in-line
or off-line, to share our respective experience on the subject.

Cheers,

    vincent.

---------------------- http://www.inrialpes.fr/planete/people/roca/
  INRIA Rhone-Alpes - projet planete      [email-masked]
  Zirst; 655 av. de l'Europe; Montbonnot  phone (+33) 4.76.61.52.16
  38334 ST ISMIER cedex - France          fax   (+33) 4.76.61.52.52
_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: "Rami Lehtonen" <[email-masked]>
Date: Thu, 13 Feb 2003 13:18:34 +0200

> pity to define a file delivery standard that cannot be used for the

Why this can't be used in the Internet? In my understanding the ALC base
layer is always delivered to receivers and that can't be congestion
controlled (of cource you can leave ALC session...). Why this is any
different? Of course you don't have extra layers for higher bandwidth
receivers.

- Rami

---

From: Vincent Roca <[email-masked]>
Date: Thu, 13 Feb 2003 14:18:10 +0100

Hi Rami,

> different? Of course you don't have extra layers for higher bandwidth

A fixed rate transmission cannot be considered TCP-friendly
as it provides no means for receivers to adjust their reception
rate. Remind that congestion control is one of the basic
requirements identified by RFC 2357.

You're right in the sense that the base layer, with layered
congestion control protocols, is supposed to be sufficiently
low not to cause congestion. This is an intrinsic limitation,
right. But there is an easy way of increasing the reception
rate: add layers. On the opposite, with a single layer, the
only solution is to increase the transmission rate, well above
the reasonable minimum...

Besides, with a single layer you can't support heterogeneous
receivers, which is one of the main assets of ALC over single
rate NACK/ACK-based protocols...

  vincent