Subject: RE: [Rmt] EXP2ST: FLUTE & ALC - "payload id" as part fo payload notheader

From: [email-masked]
Date: Mon, 27 Jun 2005 14:17:22 +0300

Good points Mike.

So:
- FEC Payload ID is not LCT header (everyone would agree :)
- FEC Payload ID _might_ be classed as ALC header
- FLUTE inherits the ALC position (also hard to disagree with)

Since it's just about clarity and two people meaning the same thing when they talk about (e.g.) FLUTE paylaod and header is important to state the ALC classification and that's all.

Like Mike, I also had the impression that FEC Payload ID is (or at least "feels like") header so making this clear in ALC would be helpful. (OTOH, there's no techical difference how these are labelled so whoever's willing to write the text - either way - get's my support :)

Cheers, Rod.

> -----Original Message-----
> From: ext Michael Luby [mailto:[email-masked]]
> Sent: Thursday, June 23, 2005 10:43 PM
> To: Walsh Rod (Nokia-NRC/Tampere); [email-masked]
> Cc: Michael Luby; Mark Watson; Lorenzo Vicisano and JoAnn
> Subject: RE: [Rmt] EXP2ST: FLUTE & ALC - "payload id" as part 
> fo payload
> notheader
> 
> 
> Hi Rod,
> Thanks for spearheading the task of starting to move FLUTE 
> from Experimental
> to Proposed Standard.  I was hoping that you would take the bait. ;)
> 
> I need to look at it, but the way I have been thinking about 
> it all along
> (and I'm not completely sure, so I do need to take a look at 
> it) is that
> 
> LCT BB
> FEC BB and
> Congestion control ...
> 
> are all building blocks that ALC brings together as a protocol
> instantiation.
> 
> Thus, LCT BB doesn't even discuss FEC (except 
> informationally), and thus FEC
> is not even necessarily used with the LCT BB (they are 
> completely disjoint).
> 
> Similarly, the FEC BB doesn't even discuss LCT (except 
> informationally), and
> thus LCT is not even necessarily used with the FEC BB.
> 
> However, from the ALC PI point of view, that brings these two building
> blocks together, both the LCT header and the FEC Payload ID 
> are part of the
> ALC header.
> 
> Again, I'll have to look at it again to verify this view, but this is
> conceptually how I think of it at least.
> 
> I also will take this opportunity to reiterate that also the 
> FEC BB and the
> LCT BB and the ALC PI are also being revamped to move them 
> from Experimental
> to Proposed Standard, and for example some of the things that 
> FLUTE does are
> being incorporated into the new FEC BB (like the file 
> partitioning), so in
> any case it will be good to closely coordinate the effort.  
> Right now, Mark
> Watson is spearheading moving FEC BB from Experimental to 
> Proposed Standard,
> and Lorenzo Vicisano is spearheading moving LCB BB and ALC PI from
> Experimental to Proposed Standard.
> 
> Best, Mike
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Thursday, June 23, 2005 6:01 AM
> > To: [email-masked]
> > Subject: [Rmt] EXP2ST: FLUTE & ALC - "payload id" as part fo payload
> > notheader
> >
> >
> > The combination of figures have caused confusion to some 
> FLUTE newbies:
> > LCT fig. 1 (RFC 3451)
> > ALC fig. 1 and fig. 2 (RFC 3450)
> > FLUTE fig. 1 (RFC 3926)
> >
> > In actual fact all are correct. It is just about wherther FEC
> > paylaod ID (of ALC & FLUTE) is header or not. It seems to me that
> > it is LCT payload (not LCT header) and so it would be more
> > correctly classed as part of the segmentation/encoding specific
> > part of the FLUTE and ALC payload - and not header.
> >
> > If this view is common, then I suggest making a couple of
> > additions to the right of the fig. 1 in FLUTE and ACL showing the
> > part which is LCT header and the part which is LCT payload to
> > make it deadly obvious. No functionality changes (just a few
> > extra characters in the spec.) so I assume this is not 
> controversial.
> >
> > Cheers, Rod.
> >
> > _______________________________________________
> > Rmt mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rmt
> >
> 
> 

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