headers
toni.paila | 1 Feb 2006 12:06
Picon

RE: EXT_TIME: a new HE for timing information in LCT

Hello Vincent and the rest of RMT WG,

Analyzing the current 3GPP, DVB and OMA specifications making use of
ALC/LCT, I found that the change you proposed does not break anything.
That is, the following specifications do not make use of either SCT or
ERT.

DVB Document A099, "IP Datacast over DVB-H: Electronic Service Guide
(ESG)"
 *
http://www.dvb-h-online.org/PDF/a099.tm3348r2.cbms1199r14.IPDC_ESG.pdf

DVB Document A101, "IP Datacast over DVB-H: Content Delivery Protocols
(CDP)"
 *
http://www.dvb-h-online.org/PDF/a101.tm3350r3.cbms1167r12.IPDC_Content_D
elivery_Protocols.pdf

Open Mobile Alliance, "Service Guide for Mobile Broadcast Services -
Draft Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST_Service-Guide-V1_0_0-20060106-D.zip

Open Mobile Alliance, "File Distribution and Stream Distribution - Draft
Version 1.0"
 *
http://member.openmobilealliance.org/ftp/public_documents/bac/BCAST/Perm
anent_documents/OMA-TS-BCAST-Distribution-V1_0_0-20060106-D.zip
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thorsten Lohmar (AC/EDD | 1 Feb 2006 12:38
Picon
Favicon

RE: EXT_TIME: a new HE for timing information in LCT

Hello Toni, et al.

good survey. Here are some "latest news" on the use of SCT in the 3GPP
specifications: I am currently drafting a CR to make the SCT in the TS
26.346 optional. 

The reason to use the SCT was, the mobile phones are not necessarily
time synchronized with the network. Therefore, we needed a base to
interpret the FDT expiration time. But, TS 26.346 includes since the
last meeting a time synchronization scheme. MBMS Ues are now
time-synchronized with the network. This makes the SCT obsolete (even
increases complexity).

BR,
/Thorsten

> -----Original Message-----
> From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On 
> Behalf Of toni.paila <at> nokia.com
> Sent: Wednesday, February 01, 2006 12:06 PM
> To: vincent.roca <at> inrialpes.fr; rmt <at> ietf.org
> Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT
> 
> Hello Vincent and the rest of RMT WG,
> 
> Analyzing the current 3GPP, DVB and OMA specifications making 
> use of ALC/LCT, I found that the change you proposed does not 
> break anything.
> That is, the following specifications do not make use of 
> either SCT or ERT.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Watson | 1 Feb 2006 17:34
Favicon

RE: EXT_TIME: a new HE for timing information in LCT

Vincent,

Looks good - I have two comments:

- the bits that previously indicated the presence of SCT and ERT should
just be 'reserved' - I would not anticipate future use without defining
a new protocol version
- it should be specified that if there are additional fields in the
EXT_TIME after the SCT, ERT and SLC then these should be ignored by
receivers, to allow more to be added in future in a backwards compatible
way.

I can include the proposal in the next LCT draft revision and address
these comments, so no need to do a new draft of your proposal (if you
agree with the comments!).

Also - the link to the LCT draft in the I-D directory has (finally) been
corrected, so could I ask if anyone has comments on LCT generally which
I should incorporate into the next update (which I am planning to do in
time for the next meeting). 

Regards,

Mark

-----Original Message-----
From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On Behalf Of
Vincent Roca
Sent: Tuesday, January 31, 2006 7:18 AM
To: rmt <at> ietf.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vincent Roca | 2 Feb 2006 09:21
Picon

Re: EXT_TIME: a new HE for timing information in LCT

Hello Mark,

>Looks good - I have two comments:
>
>- the bits that previously indicated the presence of SCT and ERT should
>just be 'reserved' - I would not anticipate future use without defining
>a new protocol version
>  
>
You're right, "future use" is ambiguous. Remove it.

>- it should be specified that if there are additional fields in the
>EXT_TIME after the SCT, ERT and SLC then these should be ignored by
>receivers, to allow more to be added in future in a backwards compatible
>way.
>  
>
Good point too.

>I can include the proposal in the next LCT draft revision and address
>these comments, so no need to do a new draft of your proposal (if you
>agree with the comments!).
>
>  
>
Yes you can.

>Also - the link to the LCT draft in the I-D directory has (finally) been
>corrected, so could I ask if anyone has comments on LCT generally which
>I should incorporate into the next update (which I am planning to do in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod.Walsh | 3 Feb 2006 13:50
Picon

RE: EXT_TIME: a new HE for timing information in LCT

Hi Thorsten

Normative SCT behaviour is defined in ยง7.7.7 and Annex A of TS 26.346. Whereas it makes sense to make a
change request (CR) to that 3GPP document, the change is a stop gap only. This HE change will also change the
name of the flags in LCT so if TS 26.346 is to reference the actual standards track RFCs, it would be
sufficient to remove the SCT flag and field parts from the TS.

It is essential that the CR also does this to the ERT! In fact, simple changing the document to say both SCT and
ERT flags are set to zero (and leaving the reference to experimental LCT RFC) would be fine - and not even
cause problems if the experimental reference doesn't get changed to standards track.

Given that the new LCT is not yet an RFC (and doesn't yet have the HE change), it's pointless to say in the 3GPP
document whether this timestamp HE is mandatory, optional or excluded from the 3GPP doc. Like other
header extensions not using mandatory LCT flags, it's best if the TS simply does not mention these.

Cheers, Rod.

PS The intent of making SCT mandatory in 3GPP was to keep the header as fixed as possible and so simplify
implementation. (FDT expiry time synchronisation suggestions followed after). In anycase, the
proposed HE change simplifies this mandatory LCT part more so it fits with the original 3GPP agreement.

>-----Original Message-----
>From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On 
>Behalf Of ext Thorsten Lohmar (AC/EDD)
>Sent: 01 February, 2006 13:38
>To: Paila Toni (Nokia-M/Espoo); vincent.roca <at> inrialpes.fr; rmt <at> ietf.org
>Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT
>
>Hello Toni, et al.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod.Walsh | 3 Feb 2006 13:50
Picon

RE: EXT_TIME: a new HE for timing information in LCT

Good points Mark. 

>- the bits that previously indicated the presence of SCT and 
>ERT should just be 'reserved' - I would not anticipate future 
>use without defining a new protocol version

Yes, this is the intent.

>- it should be specified that if there are additional fields 
>in the EXT_TIME after the SCT, ERT and SLC then these should 
>be ignored by receivers, to allow more to be added in future 
>in a backwards compatible way.

Yes. I'm not sure what normal RFC convention would be but my gut feeling
is that its best not to make normative behaviour - i.e. "these bits are
ignored" and not "these bits SHOULD be ignored". In this way another
spec using those bits isn't altering normative ALC behaviour.

Cheers, Rod.
Permalink | Reply | 0 comments |
headers
Mark Watson | 3 Feb 2006 19:03
Favicon

RE: EXT_TIME: a new HE for timing information in LCT

Hi Rod,

This section question is actually a subtle on of who 'owns' that part of
the protocol. If we normatively require that ALC-compliant receivers
ignore additional data fields in the EXT_TIME then noone can add such
fields without being non-compliant to ALC. Of course we (the IETF) can
define updates to ALC which introduce new fields and change this
behaviour. So then we (the IETF) really own that part of the protocol.

If we just say that receivers 'SHOULD' ignore such additional fields,
then users of ALC (e.g. other standards bodies) can define such fields
without their receivers being non-compliant to ALC. But then the IETF
could not introduce such fields in a future revision of ALC without
potentially stepping on uses which have been defined elsewhere.

If we really want to open the possibility for other bodies to extent
this part of the protocol, then the correct approach is an IANA registry
for these time fields.

Personally, I feel that the overhead of an IANA registry is not
justified for these time fields and that IETF should retain full
ownership of this part of the protocol. So then the compatibility
behaviour should be normative so that other usages cannot sneak in
without being described in IETF - a short RFC to introduce a new time
field is a pretty simple thing in the unlikely event that it is ever
needed.

...Mark

-----Original Message-----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rod.Walsh | 6 Feb 2006 09:26
Picon

RE: EXT_TIME: a new HE for timing information in LCT

Hi Mark

I agree with your argumentation.

I think we got caught in requirement words though. For me "...SHOULD..."
is the normative text - it's a hard requirement and, at least for the
public Internet, means that you have to have a pretty special reason to
go against it. Using the field in the way we anticipate it's use, seems
a fairly ordinary reason. "...bits are ignored..." is like "...will
be..." and is not requirement-speak. We should ignore that English
grammar that says "will" is stronger than "SHOULD" and stick with the
keywords where any experienced RFC reader will see "...will be..." as an
expectation, not a requirement. <Sorry about the academic tone - this
confusion is already enough to justify fining better language than
"...will be...">

If you read my mail with this in mind you'll see we're on the same page
for the bits I wrote about.

As for IANA registration - it's the same as specifying it in the RFC but
with less process overhead (new version of LCT not needed, just small
additional RFC for each registration). There are a few "reserved bits"
which fit into this "new LCT version" category. However, I think this is
overkill for all (or most) of the bits we have left over from 32-bit
alignment. IMHO, it's enough that basic LCT implementations are aware
that the field is there and generally set to zero; and fancy new
implementations (e.g. something like "time rich ALC") can use it however
they wish with no need for global reservation. It's like FLUTE in a
sense - the client needs to understand it's FLUTE if it's to use the
FLUTE semantics and some kind of general LCT client would be lost.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Magnus Westerlund | 6 Feb 2006 10:46
Picon
Favicon

Re: [Rmt] SDP descriptors for ALC

Hi Imed and Rod,

I do have some comments on your proposal.

First of all why have both a=flute-tsi and an a=alc-tsi. Wouldn't a 
a=tsi attribute be more appropriate. To my understanding there is no 
difference in TSI between the two. Also if some other fully specified 
protocol uses TSI they can reuse the TSI attribute. As the protocol will 
identify if it is flute or ALC, or something else in the future I don't 
see a risk of misinterpretation. The same comment applies also to the 
channel attribute. However here something more than a=ch is probably a 
good thing to indicate that it is the number of transport channels 
rather than related to media. Maybe a=trn-ch?

I am also concerned by the use of * and no rules for the ALC/UDP 
protocol. Having something that is underspecified but no defined rules 
for how fully specified mechanisms are identified seem to be a bad 
choice. I would recommend that one uses some type of identifier space 
here. I don't think media types are the correct one, but some space 
should be set up to identify applications.

cheers

Magnus

--

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod.Walsh | 6 Feb 2006 14:23
Picon

RE: EXT_TIME: a new HE for timing information in LCT

FYI - I clearly blew a fuse at the weekend when writing the last email
so please scrap the last 2 paragraphs on "HE length calculations". Now
I'm mostly sane again I realize I should have gone to HEL. (HEL being
the header extension length field which has solved this problem almost
since the dawn of man :)

Thank you Vincent for very kindly pointing this out. (I would have
forgiven much more brutal words for this magnitude of gaff :)

Cheers, Rod.

>-----Original Message-----
>From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] 
>Sent: 06 February, 2006 10:27
>To: mark <at> digitalfountain.com; vincent.roca <at> inrialpes.fr; rmt <at> ietf.org
>Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT
>
>Hi Mark
>
>I agree with your argumentation.
>
>I think we got caught in requirement words though. For me 
>"...SHOULD..."
>is the normative text - it's a hard requirement and, at least 
>for the public Internet, means that you have to have a pretty 
>special reason to go against it. Using the field in the way we 
>anticipate it's use, seems a fairly ordinary reason. "...bits 
>are ignored..." is like "...will be..." and is not 
>requirement-speak. We should ignore that English grammar that 
>says "will" is stronger than "SHOULD" and stick with the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane