Subject: [Rmt] NORM BB & PI naming

From: <[email-masked]>
Date: Tue, 21 Feb 2006 10:43:45 +0200

Hi Brian, Carsten, Mark, Joe

(sorry for the dumb question but...)

What's the reason for naming both BB and PI "NORM"?

Surely if it is only ever anticipated that NORM-PI would use NORM-BB
then having them in a single document would be better. Or (as I would
have thought) if having any number of PI's based on NORM-BB is allowed,
wouldn't it be better to use a name other than NORM for the PI. (e.g. if
ALC and FLUTE were also called LCT, it would get confusing).

(This is one of those general curiosity questions, not at all important
to the actual specification content)

Cheers, Rod.

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

---

From: Brian Adamson <[email-masked]>
Date: Tue, 21 Feb 2006 09:31:03 -0500

Not a dumb question ... the answer is probably one of a lack of 
creativity ;-).  I see your point about the possible confusion for 
NORM-BB vs NORM-PI.   It might actually make more sense to rename the 
building blocks document to something like "Multicast NACK Building 
Blocks"  since it is principally focused on issues related on "how 
to" make a usable protocol that uses NACKing ...

NORM was named "Nack-Oriented" to imply that NACK feedback was its 
principle reliability mechanism but not to overlook the support the 
protocol provides for hybrid proactive FEC operation and its optional 
additional mechanisms for ACK, etc to support some fundamental group 
communication control activity if applications need it ...

-- 
Brian

Brian Adamson
<[email-masked]>

---

From: "Sami Peltotalo" <[email-masked]>
Date: Wed, 22 Feb 2006 09:48:00 +0200

Hi,

Can someone give simple answers for the following questions? Why the NORM-PI 
does not use ALC/LCT in the multicast link and only some own NACK messages 
in the unicast link? Why to specify two protocols for overlapping use?

Cheers,
Sami

----- Original Message ----- 
From: "Brian Adamson" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 21, 2006 4:31 PM
Subject: Re: [Rmt] NORM BB & PI naming

> Not a dumb question ... the answer is probably one of a lack of creativity 
> ;-).  I see your point about the possible confusion for NORM-BB vs 
> NORM-PI.   It might actually make more sense to rename the building blocks 
> document to something like "Multicast NACK Building Blocks"  since it is 
> principally focused on issues related on "how to" make a usable protocol 
> that uses NACKing ...
>

---

From: Brian Adamson <[email-masked]>
Date: Fri, 24 Feb 2006 09:06:03 -0500

I presume your question is why NORM and ALC/LCT do not use common 
packet formats?  There probably could be a little more commonality, 
but NORM and ALC/LCT were developed as two different threads with 
some different objectives:

ALC/LCT are expected to operate without feedback and use a layered 
approach to congestion control while

NORM utilizes NACK feedback to support reliability and works under a 
single rate (with respect to each sender) congestion control paradigm 
... so there is content in the NORM header that contributes to 
receiver feedback timer scaling, etc.

While the RMT group took a "building block" approach with some 
protocol functions (e.g. FEC and NORM and ALC/LCT do use common 
payload id and FEC semantics), there wasn't a building block approach 
with respect to common protocol message structure.  We have some 
commonality there with header extensions (NORM uses the same header 
extension format as LCT and I have attempted to provide some common 
ground with FEC Object Transport Information, etc ... this was 
discussed a little at the last RMT meeting with respect to IANA name 
spaces for such things as header extension identifiers, etc ... But, 
at this point NORM and LCT are independent protocol instantiations 
since none of the building blocks mandate specific packet formats, 
etc ...

With respect to NORM, it has several message header fields that 
convey information from the sender(s) to the receivers concerning 
scaling of feedback timers, etc (grtt, group size, etc) ... While 
NORM header content lets receivers join a group in progress with 
little pre-configuration and no need to know specific sender(s)' 
settings, I recognize that the headers are a little bulky and may be 
overkill for some applications where the parameter information (FEC 
details, etc) (with respect to a sender) could be conveyed to 
receivers as out-of-band information (e.g. in an SDP message, etc) 
... So I am considering how there might be a way to use a bit or two 
in the header (particularly the NORM_DATA) message to indicate a 
header semantic that indicates whether the "full, detailed" set of of 
header fields is present or a more compact, reduced header (this 
might look more like an LCT header?)

At 9:48 AM +0200 2/22/06, Sami Peltotalo wrote:
>Hi,
>
>Can someone give simple answers for the following questions? Why the 
>NORM-PI does not use ALC/LCT in the multicast link and only some own 
>NACK messages in the unicast link? Why to specify two protocols for 
>overlapping use?
>
>Cheers,
>Sami
>
>----- Original Message ----- From: "Brian Adamson" <[email-masked]>
>>NORM-BB vs NORM-PI.   It might actually make more sense to rename 
>>the building blocks document to something like "Multicast NACK 
>>Building Blocks"  since it is principally focused on issues related 
>>on "how to" make a usable protocol that uses NACKing ...
>>
>>protocol provides for hybrid proactive FEC operation and its 
>>optional additional mechanisms for ACK, etc to support some 
>>fundamental group communication control activity if applications 
>>need it ...
>>
>>
>>

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>