[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
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" :)
Cheers, Rod.
________________________________
From: rmt-bounces at ietf.org [mailto:rmt-bounces at ietf.org] On
Behalf Of ext Mark Watson
Sent: 12 October, 2005 19:13
To: rmt at ietf.org
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
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt