Subject: Re: [XCON] Floor Control Draft

From: "Chris Bennett" <[email-masked]>
Date: Wed, 12 May 2004 11:45:29 -0700

Hi all --

I am with Togabi Technologies.  We are a startup working on Push to Talk over Cellular.  We have been involved in the OMA PoC work for a while now, and I have also been monitoring the XCON mailing list.  Since we have a particular interest in floor control for PoC, I thought it might be worth offering a few general comments on the draft XCON BFCP from a PoC- and OMA-oriented viewpoint.

In Togabi's view, the key issue is to make PoC work as effectively as possible over a very narrowband channel.   On CDMA networks, we are looking at a 9.6 kbps fundamental channel.  In GPRS the constraint is a single timeslot with CS1 encoding -- 8 kbps.  This has to cover all media and all overhead, down to the MAC layer.  Further, while network enhancements like ROHC are coming down the pipe quite fast, there is strong pressure to get a PoC standard finalised this year with deployment as soon as possible thereafter.  This pressure includes interest from customers who are looking only to deploy a PoC application, and may not upgrade their networks for some time.  So, the FCP solution needs to work well in a very constrained environment, meaning that overhead costs which may be tolerable in other environments have to eliminated if possible.

From this perspective, a text-based FCP is a nonstarter for OMA, whatever value it may have elsewhere.  Fielded proprietary PoC systems which used SIP INFO to deliver floor control have had to rework  their FCP because of the performance inefficiencies involved.  While I think Togabi's views on nearterm performance efficiency are not universally shared in OMA, I'm sure you would find general agreement there that a binary approach is required.  

As in XCON, there is a debate in OMA as to what should be used as the transport protocol for an FCP.  The main camps are not UDP vs TCP, however, but RTCP (via APP packets) vs RTP (via Extended Header).  Both camps assume RT(C)P over UDP.  

It's hard for me to put the argument for the RTCP position since, frankly, I don't understand what advantages it offers over a straight UDP (or TCP) transport, as in the proposed XCON BFCP.  The proposal is coupled with a proposal to suspend RTCP's compounding and periodic transmission requirements for these APP packets, so that you use them transactionally, and if you do this I don't think you have RTCP any more.  Hopefully a proponent monitoring this list can step in to present a more positive picture.  This proposal has a lot of support in OMA.  It is backed by a number of companies who have brought in a "consortium specification" to OMA, and allied carriers.  It may well prevail for this reason if no other.

The RTP position has mostly actively been championed by ourselves, although it has had some support from other companies such as Nortel and Huawei, and has some outside academic support -- see http://research.ac.upc.es/EW2004/papers/144.pdf .  Our argument is that there are some FCP transactions which interact with the media, notably those that signal new speakers, end of talk bursts, and, most importantly, queue status updates, if the FCP supports queued requests (which is optional in OMA).  The first two require synchronisation with media.  The last doesn't, but will typically be sent concurrently with PoC media and in the same direction, so can induce jitter across the radio link.  By using RTP Extended Headers, it is possible to tunnel these FCP messages through the media channel, eliminating the lower-layer overhead for these messages.  Whether OMA deems this effect significant enough on narrowband channels to be useful remains to be seen.

[Since the point has come up in OMA, it is perhaps worth saying here that use of an RTP-based format doesn't mean that FCP must use the same ports as an RTP media stream, only that it becomes possible to do so when advantageous.]    

As for Gonzalo's draft, my reaction is that its a good start.  Its clear from other comments that a lot of clarification is needed on details and I don;t really have much to add to those.  There are certainly aspects of it -- such as ChairAction -- which look rather complex and are simply not needed for the OMA application.  In Togabi's own work on FCP, we came up with a kind of micro-TLV+BER syntax to allow for expansion of parameters to arbitrary lengths while keeping it very compact for the usual case, but this type of optimisation is only of value on very narrow channels, and only when the FCP body is of the order of the transmission overhead, so its not clear to me its of interest to XCON.

I would say, though, that if XCON would like OMA to adopt an XCON BFCP for PoC, it will have to move fast.  The OMA FCP signalling flows and choice of bearer protocol are scheduled to be settled the week after next, and the target is to have OMA PoC stahdards ready by year end.

Regards,
Chris Bennett

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 May 2004 00:44:30 -0400

inline.

Chris Bennett wrote:

> The RTP position has mostly actively been championed by ourselves, 
> although it has had some support from other companies such as Nortel and 
> Huawei, and has some outside academic support -- see 
> http://research.ac.upc.es/EW2004/papers/144.pdf .  Our argument is that 
> there are some FCP transactions which interact with the media, notably 
> those that signal new speakers, end of talk bursts, and, most 
> importantly, queue status updates,

RTP already provides a facility for signaling the speaker - its the 
CSRC, and the RTCP CNAME provides a mapping of that SSRC to a specific 
user. Talkspurt indications are provided by the market bits. I don't see 
either of those as floor control, though clearly they belong in RTP.

For the other floor control primitives, I don't see the specific need 
for coupling with the media stream.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Chris Bennett" <[email-masked]>
Date: Thu, 13 May 2004 09:42:37 -0700

Jonathon --

Thank you for your comments.

> either of those as floor control, though clearly they belong in RTP.

On FCP design, I agree that a change in RTP CSRC could be used by the FCP as
an implicit signal for a change of floorholder if it is present.   However,
the CSRC is only supplied if there is a mixing function, and in PoC no
mixing occurs, so there is no CSRC.

The interpretation of the marker bit is profile-dependent and the FCP needs
a means for indicating the end of talkburst that is profile-independent.

> for coupling with the media stream.

I agree that there is no logical coupling between queue status returns with
media.  That's not our claim.

Our concern is that there is a resource contention interaction when they are
transmitted concurrently, and that this is usually the case.  In PoC, the
resource is the airlink forward channel.  The effect of the contention is to
add depth to the media jitter buffer in the client, which adds to end-end
latency.

In most environments this effect is too slight to matter, but on the very
narrowband airlinks people want to use for PoC it adds over 50 ms of jitter,
unless you use link-layer header compression techniques, or the RTP
piggybacking technique when header compression is not available.

Currently the latency of packet-based PoC systems is well over a second, and
OMA has recognised this by choosing performance targets of 1.6 seconds.  But
circuit-based PoC systems are very much faster, a few hundred ms, and
several carriers are choosing circuit-based systems for this reason.

So we see the OMA specs as very much worst-case numbers, and the
circuit-based latency as defining the target we should be aiming for.  50+
ms is a significant fraction of this.  Our view is that if packet-based PoC
systems are to become competitive it is necessary to squeeze out every
unnecessary delay at every layer of the system -- including the FCP --  from
day 1.

I hope that makes the argument clearer.

Chris

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 May 2004 17:31:53 -0400

> mixing occurs, so there is no CSRC.

I think this depends on your definition of mixing. Its "easy" mixing, 
but its mixing in that the PTT server is acting as a receiver for all 
media streams, is combining them in some way (in this case, discarding 
some), and sending the results out to the other participants.

> a means for indicating the end of talkburst that is profile-independent.

Why?

> piggybacking technique when header compression is not available.

There can, of course, be other packets that might get delivered to the 
mobile from other applications. You have an implicit assumption that the 
PTT application server is, basically, the only entity transmitting 
packets to the mobile, and therefore you are having it perform functions 
traditionally done at the link layer - namely the scheduling of packets 
on the link.

I think a better approach is to keep the protocols separate, and deal 
with these kinds of schedulign issues for a particular link either 
through custom architectures and/or link layer techniques.

In this particular case, if you co-locate the floor control server and 
the PTT application server, I don't see why the server could not simply 
send the floor control packet first, and once sent, then start 
delivering the media packets.

Of course link compression would be an even better approach.

-Jonathan R.

---

From: "Chris Bennett" <[email-masked]>
Date: Thu, 13 May 2004 17:50:49 -0700

See CJB inline

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Chris Bennett" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 13, 2004 2:31 PM
Subject: Re: [XCON] Floor Control Draft

> > Jonathon --

CJB: (Sorry for misspelling your name)

> some), and sending the results out to the other participants.

CJB: Not really.  The point of the FCP in PTT is to ensure that there is at
most one media stream transmitted to the PTT Server at any given time.  Its
a bit of a stretch to call this "mixing".

CJB:  In any case there sees to be general agreement within OMA that changes
of floorholder should be explicitly signalled and identified within the FCP,
not by relying on RTP, and I have no quarrel with that view.

> > a means for indicating the end of talkburst that is profile-independent.

CJB:  Why which?

CJB:  Why does the FCP need to indicate the end of talk burst?  So that the
server knows that the floor is released.

CJB:  Why does the FCP need to do this in a way that is media profile
independent?  Two reasons: Because making any aspect of the FCP
media-profile-dependent makes it expensive to apply it to new media
profiles.  Because profiles may exist which do not provide a means.

> traditionally done at the link layer - namely the scheduling of packets

CJB:  For many lowend PoC terminals, dedicated to the application, this will
in fact be the case.  I agree that there are many others where it won't be
the case, but this is an economically important case.

> through custom architectures and/or link layer techniques.

CJB:  Custom architectures are not an option, and for many carriers link
layer compression techniques are very likely to be available only some time
after PoC rollout.

CJB:  As a practical matter, solutions which cause CDMA supplemental
channels or additional GPRS TBFs to be activated sporadically are not looked
on favourably by many carriers, so there is a strong incentive to exert
tight control over the link-level bandwidth budget.

> delivering the media packets.

CJB:  Because in queued FCP systems your request usually only gets queued if
someone else is already speaking, and the server doesn't know how long the
talk burst is going to last.

> Of course link compression would be an even better approach.

CJB:  Agreed, where available.  Of course, the temptation will be to use the
bandwidth gained to reduce voice latency and improve quality, so its still
desirable to keep other activities under control.