RE: [EXP2STD] Remaining LCT and ALC issues

Comments below (start with ***).

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, November 09, 2005 3:47 AM
To: [email protected]; [email protected]
Subject: RE: [Rmt] [EXP2STD] Remaining LCT and ALC issues

Hi Mark et al.
 
1)     We have discussed previously (and there is reference in the FEC
BB) the possibility for Content Delivery Protocols to provide an
indication when a packet contains only source data. This allows the
support of FEC Schemes which define different FEC Payload ID formats for
such packets - in particular FEC Payload ID information which is only
relevant to receivers supporting FEC decoding can be omitted from
packets containing only source data.

 

It's been suggested previously that one of the reserved bits in the LCT
header could be used for this purpose. However, LCT is an independent
building block from the FEC Building block. A clean implementation of
this idea would be for LCT to define these two reserved bits as
available for Protocol Instantiation-specific use and for ALC to define
the usage above.

 
This remains unclear to me. Surely the FEC Payload ID is essential to
all packets include source data, for reconstruction to source block and
objects? Please help my slow brain with an explanation.

*** LCT does not imply the use of FEC or vice-versa, i.e., LCT is a building
block that could be used for another protocol that doesn't use FEC at all.
It is only ALC that binds the various building blocks together to form a
protocol instantiation, and in particular ALC binds together LCT and FEC.
Thus, as Mark observed, ALC is the correct place to say that these one or
two bits in the LCT header are used specifically for FEC, and within LCT the
two bits should be reserved for Content Delivery Protocols (protocol
instantiations) for whatever they want to use them for.
 
BTW I'm happy with the 2 bits being reserved for unspecified use.
 
2)     It has been suggested that the present definition of Sender
Current Time (ms since the start of the session) is not very useful and
it might be better to replace it with an NTP timestamp. Particularly in
the case of FLUTE this would mean that the SCT and FDT Expiry times
would be expressed in the same format and relative to the same clock.

 

I like this idea. However, this is a significant change if SCT has been
used and the message needs propagating to current FLUTE implementers,
DVB-CBMS, OMA-BCAST and 3GPP-SA4 to give them time to comment. Given the
target for standards track this year, that seems unlikely.

*** I don't think 3GPP SA4 ever uses the SCT (should be checked) and I'm
pretty sure the same is true for DVB-CBMS (should be checked).  I have no
clue about OMA-BCAST, but it is worth checking.  If none of these use SCT
then it seems like this is pretty easy to do now and should be done,
otherwise I agree with you Rod.

 
 
3)     ALC includes a statement that the IETF had been notified of
Intellectual Property Rights with respect to ALC. According to the IETF
IPR pages, this is incorrect and so I propose to remove this statement.

 

I thought this was correct. Are the ALC authors aware of some hidden
IPRs which are not yet declared? (Please let the answer be "no" :)

*** I think you misread what Mark was saying Rod.  The ALC Experimental RFC
says that the IETF had been notified of IPR with respect to ALC, and Mark is
saying that there is no such IPR declared against ALC in the IETF IPR pages,
and thus the statement that the IETF has been notified of IPR with respect
to ALC should be removed from ALC.

 

Cheers, Rod.

 
 



________________________________

	From: [email protected] [mailto:[email protected]] On
Behalf Of ext Mark Watson
	Sent: 12 October, 2005 19:13
	To: [email protected]
	Subject: [Rmt] [EXP2STD] Remaining LCT and ALC issues
	
	

	All,

	 

	Three final issues with the update of these two:

	 

	1)     We have discussed previously (and there is reference in
the FEC BB) the possibility for Content Delivery Protocols to provide an
indication when a packet contains only source data. This allows the
support of FEC Schemes which define different FEC Payload ID formats for
such packets - in particular FEC Payload ID information which is only
relevant to receivers supporting FEC decoding can be omitted from
packets containing only source data.

	 

	It's been suggested previously that one of the reserved bits in
the LCT header could be used for this purpose. However, LCT is an
independent building block from the FEC Building block. A clean
implementation of this idea would be for LCT to define these two
reserved bits as available for Protocol Instantiation-specific use and
for ALC to define the usage above.

	 

	2)     It has been suggested that the present definition of
Sender Current Time (ms since the start of the session) is not very
useful and it might be better to replace it with an NTP timestamp.
Particularly in the case of FLUTE this would mean that the SCT and FDT
Expiry times would be expressed in the same format and relative to the
same clock.

	 

	3)     ALC includes a statement that the IETF had been notified
of Intellectual Property Rights with respect to ALC. According to the
IETF IPR pages, this is incorrect and so I propose to remove this
statement.

	 

	Comments ??

	 

	Regards,

	 

	Mark


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