Subject: Re: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps

From: Vincent Roca <[email-masked]>
Date: Wed, 06 Mar 2002 16:57:21 +0100

Mike and al.

Here are some comments on the ALC draft-06.
Beyond the few comments made, I really like it!
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

	Comments on draft-ietf-rmt-pi-alc-06.txt
	----------------------------------------

Main comments
-------------

* section 2.1, p 10:
A session is now identified by the (sender IP addr, TSI). It's fine
as long as the sender's IP addr of an incoming packet (e.g. as
obtained with a recvfrom() syscall) is actually that of the sender.
But it's a problem if the sender's site uses NAT (the sender does
not easily know in advance its IP address).
It will also be broken if a SIMPLISTIC reflector is used (e.g. to
easily provide multicast connectivity to hosts that do not have
access to ASM/SSM routing).

The ALC draft may relax a little bit this constraint by saying that
the TSI can be the result of a hash between the sender's IP address
and a unique local session identifier. In that case, if we accept
the small probability that two sessions from two different senders
use the same TSI, the session is only identified by the TSI.
So there could be two different modes:
	- (sender IP addr, TSI)
	- TSI only
The sender chooses one and announces it in the session description.

* section 4.4, p28:
It is said that when authentication is used, then it should be
checked immediately, before step 1 (header parsing).
I think on the contrary that authentication should be checked just
before step 3 (CCI processing) since:
	- it requires going through the LCT header, which is not
	possible until this header has been parsed/checked
	- step 2 (TSI check) will automatically (and efficiently!)
	discard all packets that are not part of the session

* section 2.4, p 12:
I think it's a bit restrictive to require that all the objects be
known in advance with multi-object sessions (this is assumed when
saying that the set of TOIs and the object length must be
communicated to receivers before joining the session).
In our implementation this info is communicated in-band dynamically.
It gives more flexibility to application designers and increases
the ALC field of application.
The constraint here is to have a means to communicate this
information in-band. We do it with a "private" ALC header extension
that indicates the set of TOIs in the session (once it is known).

* section 2, p9 vs. section 4.1, p21
There is a confusion. It is said that ALC assumes there is a single
sender (p9) and later (p21) "the object that is being transmitted
from several senders concurrently" (maybe this latter sentence only
applies to LCT?)

Anyway why should ALC be restricted to a single source ?
Because it can be used with SSM ?
Because having several sources sending to the same channel creates
problems and inefficiencies in the congestion control building block
of each receiver ?

Maybe we can say that ALCv1 is primarily designed for sessions
with a single sender, and that the case of multiple senders
contributing to the same session may be possible but leads to
problems that are not addressed in this document.

Suggestions / clarification needed
----------------------------------

* section 2.1, p10: Why is it said that each TOI "should be
globally unique across all sessions" ? As long as a session is
uniquely identified, then (sender addr, TSI, TOI) is unique, no
matter if TOI is the same or not.
In some implementations the TOI is a counter, not a hash!

* Is TSI == 0 a valid TSI? I think yes (and the draft does not
forbid it). In that case having a TSI field in each packet wastes
32 bit.
So I'd replace the sentence:
"For ALC the length of the TSI field is required to be non-zero"
by: 
"For ALC the length of the TSI field is required to be non-zero
if TSI > 0. If the 'S' flag is 0 (no TSI field), it is assumed that
TSI == 0."

* Same kind of remark for TOI.
As TOI = 0 is valid for sessions with several objects, we can
assume that when the 'O' flag is 0 (no TOI field), TOI == 0.

* A suggestion I already made some time ago:
Change the "source block number" (of the FPI) to
"source block ID" as its goal is to identify the source block.
"Source block number" may be confused with the number of source
blocks" (even if it is clarified in the text).

* section 4.4, p28:
Why should a receiver experiencing several authentication failures
leave the session ? Why not just receiving the base layer as
suggested above ? In most cases if a receiver experiences an
authentication failure, there is a very high probability that more
failures will take place during some time...

Typos / minor
-------------

* p4, 2nd paragraph: "the goal is to deliver" instead of
	"is to delivery"
* p4, bottom: "protocol" instead of "protcol"
* p18, ERT paragraph: replace '/' in "session / object" by "or"
	which is more explicit
* p12, 4th bullet: "the address and port number used..." instead of
	"addressES" and "numberS"
* p27, middle: replace "A receiver may be concurrently joined to..."
	by: "A receiver may concurrently join..."
* p28, middle: add a final 's' to "check" in sentence "...that the
	rx immediately checkS the authenticity..."
* p28, bottom: it is said that a MD5 check be made before delivery
	to an application. For the point of view of ALC, whatever is
	above ALC is the application. So I'd say:
	"...It is therefore recommended that an application built
	on top of ALC make an integrity check on received content,
	e.g. ..."

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 6 Mar 2002 12:38:38 -0800

Vincent,
I've copies your attached comments below and have interspersed my replies
(starting with ***) into your comments.
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 7:57 AM
To: Michael Luby
Cc: [email-masked]; [email-masked]; Lorenzo Vicisano; Roger
Kermode
Subject: Re: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps

Mike and al.

  vincent

Main comments
-------------

* section 2.1, p 10:

*** The idea of having the session scoped by the sender IP address was an
idea that came out of an informal meeting with several people back in the
fall at ICSI, and the consensus was that the session should be scoped by the
sender IP address.  This has been in the ALC draft since version 3, so I'm
surprised that this is coming up now. If we want to revisit this decision,
it will have to be taken up in the entire RMT working group, because this
not only affects ALC, but also GRA and several other drafts within the
group.  I personally hate the idea of using an unscoped TSI as a global
identifier, because this brings problems similar to the problems with ASM
and group address allocation, and having the group address scoped by the
sender IP address as part of the channel address is exactly what SSM does,
and this is a model that there is consensus on as having a shot of working.

* section 4.4, p28:

*** Ok

* section 2.4, p 12:

*** Ok, we can relax this to say that the object lengths must be either
communicated out of band or in band using a Header Extension, but that the
mechanism for doing this is outside the scope of the ALC document.  A
solution that to me seems cleaner in the long run than using private Header
Extensions would be to define a new FEC Encoding ID that extends FEC
Encoding ID 128 to also include the object length.  Are you up for writing a
document that would do this as specified in the FEC building block draft?
In either case, I will relax the requirement so that object lengths can be
passed either out of band or in band through header extensions.

*** ALC is explicitly NOT restricted to a single source, BUT an ALC session
IS restricted to a single source.  Again, this has been in the draft for
several versions now, so I'm surprised that it is coming up again now.  The
reason that a session is restricted to a single source is that because it
makes no sense to perform congestion control on channels that are coming
from geographically disparate sources.  ALC explicitly allows a receiver to
be joined to multiple sessions concurrently, and the same object (or
objects) to be delivered in several session concurrently, i.e., the receiver
can be joined to multiple sessions, BUT the congestion control MUST be
performed on each session separately.  That is the intent and I believe that
is what it says.

*** I think all versions of ALC should be designed to work with sessions
that are defined to be from a single sender, but the receiver is allowed to
be joined to multiple sessions from different senders and this should be
explicitly addressed at the application level.  I think anything else is
getting back to the problems found in ASM, and away from the advantages of a
model that is like SSM.  It is an application level issue to coordinate the
different sessions, and if you try to do it at the transport level the same
problems as come up with ASM arise again.

*** Good point.  It is strong enough to say that the TOI should
be unique for each object within the session.  I'll change it to this.
The reason it was stated this way is for the case when a receiver joins
multiple sessions to obtain packets pertaining to the same object,
to not get confused about which packets pertain to which object,
but this mapping between objects and TOIs can be handled at the
application level and can be different for the same object
between different sessions.

***  The TSI field is REQUIRED by LCT, and ALC uses this.  LCT allows the
flexibility of using for example the Source Port Number as the TSI (and this
has been in the LCT draft for several versions), but LCT does REQUIRE that
the TSI be carried in each data packet.  What ALC does is to specify that
the required TSI is explicitly carred in the LCT portion of the ALC header.
The TSI does not have to be 32-bits, for example it can be 16-bits if you
use a TOI that is also 16-bits.  This is achieved by the setting S=0, O=0
and H=1. The requirement is that the length of the TSI and TOI is a multiple
of 32-bits, but each can be 16-bits for example. What is disallowed is for
S=0 and H=0, i.e., a zero length TSI.

*** The TOI field can be omitted by setting O=0 and H=0.  I don't see any
difference between omitting the TOI and setting TOI = 0, so why change this?
You can within an application of course set a variable TOI=0 in the case
that the TOI is omitted, but this seems quite outside the scope of ALC.

*** This is a comment on the FEC building block, not on ALC.  We already
went over this and I don't see any compelling reason to change this.  If we
do change it, then the FEC building block (which is already through last
call) would have to be modified, which I'm not in favor of doing.

* section 4.4, p28:

*** Ok

Typos / minor
-------------

*** All ok

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

---

From: Vincent Roca <[email-masked]>
Date: Thu, 07 Mar 2002 16:59:53 +0100

Mike,

here are some answers...

> Main comments
[...]
> sender IP address.

Ok if there is a consensus around it...
Yet I assume that some implementations will offer the possibility to
remove this check as it may create problems in some cases. 

You're right, it was already in LCT-v2 draft...  At that time it didn't
strike me.

> passed either out of band or in band through header extensions.

Oups, from your answer I see that there was an ambiguity in my
original comment. Sorry!

The object length is not the only thing I was concerned about
(anyway the FEC Object Transmission Info (FTI) associated with
FEC encoding ID 128 already enables the sender to communicate this
info in-band dynamically). But ok to relax this item too.

My concern was more general: objects may not be known at all in
advance, nor their number and consequently the associated
set of TOIs.
So I'd also relax the 7th bullet of section 2.4, p 12: "If the
sessions carries packets for more than one object...".

To summarize, I'd say the 3 following possibilities are acceptable:
1- the set of TOIs can be communicated out-of-band before a receiver
  joins the session
2- the set of TOIs can be communicated dynamically by an out-of-band
  mechanism that is out of the scope of the ALC draft
3- the set of TOIs can be communicated dynamically by an in-band
  mechanism.

We are using solution 3- and we currently do that with a private
ALC Header Extension (but we can change it).
I'm not sure that specifying a new FEC Encoding ID for that is
appropriate as this need is more related to the notion of "ALC session"
than to that of FEC BB.

Yes, I can write a small paragraph for that once everybody agrees.

[...]
> IS restricted to a single source.

Ok, I fully agree with you! Let's use meta-ALC-sessions when there
are multiple contributing senders.
Maybe we can add a sentence clarifying that point in the document.

> Suggestions / clarification needed

S=0 and H=0 (zero length TSI) can be synonymous to TSI==0 in ALC which
is a valid TSI. In that case there is no need to reserve any room in
the ALC header to carry a TSI equal to 0.
It does not contradict the fact that ALC requires a session identifier
(there is one, 0), unless we say that a session identifier must
be > 0.

If TSI==0 is valid, we can assume that many ALC implementations will
use this value (at least by default).

> that the TOI is omitted, but this seems quite outside the scope of ALC.

The ALC draft says that "the TOI field must be used in all packets if
more than one object is to be tx in a session" (p21). I don't agree.
It can be said in the draft that O=0 and H=0 is synonymous to TOI == 0
and that this is valid even when more than one object is to be
transmitted in a session.
It can save some room in the ALC header (especially if TSI==0 too).

   vincent

---

From: "Michael Luby" <[email-masked]>
Date: Thu, 7 Mar 2002 12:25:33 -0800

Vincent,
More comments below.
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Vincent
Roca
Sent: Thursday, March 07, 2002 8:00 AM
To: Michael Luby
Cc: [email-masked]; [email-masked]; Lorenzo Vicisano; Roger
Kermode
Subject: Re: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps

Mike,

here are some answers...

[...]

*** So I think we agree at this point that it can remain as it is.

*** This seems ok to me.  I suggest you write the paragraph.

[...]

*** I think there are several sentences that already make this point.  If
you want to suggest another sentence and where to place it, please do that.

*** I think we need to discuss this point in the RMT working group IETF
meeting (are you going to be there?).  One philosophical point that I
believe we may differ on that I want to call out is the following.  A
building block is in general going to leave open a lot of possibilities and
be more open-ended then a protocol instantiation, because the building block
is meant to be useful for a multitude of protocol instantiations.  This
means in particular that a protocol instantiation may restrict the use of
any building block beyond what is stated in the building block spec.  Thus,
even though the LCT building block allows S=0 and H=0 as a valid setting and
thus the TSI is not carried in the LCT header, but nevertheless LCT does
explicitly require a TSI associated with the session that uniquely
identifies it within the scope of the sender IP address.  The current
version of the ALC draft further restricts its use of LCT by explicitly
requiring the TSI field to be in the LCT header.  This prevents the problem
of confusion when a receiver is subscribed to multiple ALC sessions from the
same sender.  Perhaps what we could do is to say that the TSI field is
explicitly REQUIRED if the sender sources more than one ALC session, but
that if the sender sources only one ALC session then the TSI field MAY be
omitted and it is then implicitly defined to be zero.

*** There are a couple of interpretations to what you say:
(1) One of the objects is allowed to not have the TOI in the header of
packets and then it is defined to be TOI == 0, but then all other objects in
the session MUST have a TOI that is non-zero and all unique.  This seems
like a really kludgy hack that I really don't like.  This means that you
could never explicitly use TOI = 0 as the setting of the field as otherwise
this would be confused with packets that carry no TOI field, you are only
saving header space for packets associated with one of multiple objects, and
it is overall confusing.
(2) None of the objects in the session are required to have a TOI, and then
some other means must be used by the receiver to distinguish one object from
another within the session.  This defeats the very purpose of the TOI, which
is to allow the receiver to distinguish between different objects in the
same session.
Thus, with either of the two interpretations of your comments that I can
come up with (and maybe you meant something else), I don't see the logic of
your suggestion.  Again, we can resolve this at the RMT working group
meeting at the IETF.

   vincent

---

From: Vincent Roca <[email-masked]>
Date: Tue, 12 Mar 2002 15:35:34 +0100

Mike

As you agree on the idea of adding in-band support to carry
some object information, here are the two paragraphs that I
suggest to add to the alc-06 document.
cheers,

   vincent

nb: please correct the english. I did my best but... 

<<< Vincent: add this paragraph in section 2.4, p12, after removing the 3
items
    mentioned below from the initial list >>>

Sometimes the objects that will be sent in a session are completely
known beforehand. They can be communicated to the receivers, before they
join the ALC session, in the session description which, in that case,
includes three additional items:

  o An indication of whether or not the session carries packets for more
    than one object;

  o If the session carries packets for more than one object, the set of
    Transport Object IDs (TOIs) for the objects in the session.

  o The total length of the objects in the session in bytes.

Sometimes the objects are not be known at all when the ALC session starts.
Their number, their length and the associated set of TOIs will only be
determined during the ALC session lifetime, for instance when the
application
built on top of ALC indicates that no more objects will be submitted.
In such cases several possibilities are offered:

  o the set of TOIs can be communicated dynamically by an out-of-band
    mechanism that is out of the scope of this document.

  o the set of TOIs can be communicated dynamically, in-band, by an ALC
    header extension that is defined in section 4.2 of this document.
    In this case the format of this header extension MUST be communicated
    to receivers in the initial session description before they join
    the ALC session.

  o the total length of each object can be communicated dynamically by
    an out-of-band mechanism that is out of the scope of this document.

  o the total length of each object can be communicated dynamically,
    in-band, by an ALC header extension that is defined in section 4.2 of
    this document. In this case the format of this header extension MUST
    be communicated to receivers in the initial session description before
    they join the ALC session.

<<< Vincent: add this paragraph in section 4.2, p24, after removing
    "For this version of ALC, there are no PI-specific extensions" >>>

This version of ALC defines two PI-specific header extensions:

EXT_FTI=64    FEC Object Transmission Information (FTI) extension
              The purpose of this extension is to carry in-band the FTI
              information of an object. Of course the FEC Encoding ID and
              FEC Encoding Name directly impact this extension format.
              Therefore a receiver is REQUIRED to obtain the FTI header
              extension format in the session description before joining
              the ALC session.

EXT_STOI=65 (variable-length version)
EXT_STOI=192 (32-bit version)
              Set of Transport Object Identifiers (TOIs) extension
              The purpose of this extension is to carry in-band the set
              of TOIs of the objects sent in the session.
              Since the nature of a TOI is implementation specific, this
              document does not specify the format of the STOI extension.
              A receiver is REQUIRED to obtain the STOI header extension
              format in the session description before joining the ALC
              session.
              For instance, when the TOI is a counter ranging from 0 for
              the first object to max_toi for the last object, and when
              max_toi can be encoded in a 24 bit field, a possible STOI
              extension format is the following:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | HET=192 (STOI)|               max_toi in the session          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fig. 4 - Example of STOI header extension

              This document does not specify when a STOI extension should
              be included in a packet. In particular, transmissions being
              unreliable, several packets (for instance all the packets
sent
              on the base layer) may include it. Sessions using the
On-demand 
              model may also require that a STOI extension be included in
              many packets. These considerations are out of the scope of
              this document.

---

From: Vincent Roca <[email-masked]>
Date: Tue, 12 Mar 2002 17:32:19 +0100

Mike

Here is the 2nd part.

   vincent

> you want to suggest another sentence and where to place it, please do that.

I went through the document once again but didn't find any reference to
it, maybe I missed it! Anyway, let's add at the end of the 2nd paragraph
of section 2, p9:

The fact that an ALC session is restricted to a single sender does not
preclude the possibility of having multiple contributing senders for the same
set of objects, probably by defining multiple ALC sessions in an application
built on top of ALC.  How these meta-sessions are managed is an application
specific issue that is out of the scope of this document."

> omitted and it is then implicitly defined to be zero.

I fully agree with everything you said. In particular I fully agree
with the difference in openess between a BB and a PI.
My point was just to know if TSI==0 was or not valid and what
to do when TSI==0...
I think your last sentence is ok.

> your suggestion.  Again, we can resolve this at the RMT working group

Interpretation (1) is what I meant.
The idea behind it is "do not send something that is not usefull".
If you agree with this idea, then IMHO everything becomes natural.
The parsing function at the receiver is straightforward:

if (header->O_field == 0 and header->H_field == 0 in the incoming packet)
        TOI = 0;
else
        TOI = header->toi;

and we don't care anymore in the rest of the packet processing code
wether the TOI field was or not present in the incoming packet.
If the sender doesn't like it, he may add a 0'ed TOI field, and the
final result will be the same for the receiver. But why should
he do it ?

A simple (artificial?) example: you have 2 objects, a big file
(TOI==0) and an second small one (TOI==1) containing some meta-data
on the file. Removing the TOI field of the first object may save
some bytes (depending on the H flag in fact).

And we can do exactly the same with the TSI field, when the sender
wants to use TSI==0, which, as you explained (and I fully agree),
may not be a good choice, unless the sender knows it will never
source more than one ALC session.