Re: NORM BB & PI naming

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 protected]>
>To: <[email protected]>; <[email protected]>; <[email protected]>; 
><[email protected]>
>Cc: <[email protected]>
>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 ...
>>
>>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 ...
>>
>>
>>
>>At 10:43 AM +0200 2/21/06, <[email protected]> wrote:
>>>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 protected]
>>>https://www1.ietf.org/mailman/listinfo/rmt
>>
>>
>>--
>>Brian
>>
>>Brian Adamson
>><[email protected]>
>>
>>_______________________________________________
>>Rmt mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/rmt
>>
>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt


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