Subject: Re: [rohc] Question about ROHC configuration

From: "Soyoung Lee" <[email-masked]>
Date: Tue, 3 Sep 2002 13:23:53 +0900

Dear Lars-Erik and ROHC experts,

Thanks for your comments.
But I still have some curiosity.

Let's assume just a streaming service over ROHC (i.e asymmetric bi-directional communication).
Then, one way(DL) is used for RTP (multimedia data), and of course,the other way(UL) is used for RTCP (RTP control information).
At this time, I wonder if the number of CIDs should be same for both ways.
Is it possible that 3 CIDs are used for RTP and 1 CID is used for RTCP?

And I think my earlier second question was ambiguous. 
You're right. RFC3095 says "ROHC can handle a certain number of concurrent packet streams."
But, what I want to know is that if it's possible a RTP session (for example, Video or multimedia data) 
can be divided into several packet streams and these streams are transmitted concurrently.
(I think a "channel" in RFC3095 means a session. Am I right? )
In this case, is there only one RTCP or several RTCPs for each stream?

Thanks in advance.

Best Regards,
SoYoung

 ===========================
  Soyoung Lee
  LG Electronics Inc. Korea

  e-mail: [email-masked] <mailto:[email-masked]> 
  phone: +82-31-450-7859
  fax: +82-31-450-7912
===========================

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 30, 2002 5:04 PM
To: 'Soyoung Lee'; ROHC
Subject: RE: [rohc] Question about ROHC configuration

Soyoung,

> First, when I configure the ROHC parameters, shoud I always
> configure these parameters in the compressor and decompressor
> the same? That is, the Uplink and Downlink have to be configured
> the same?

First of all, I am not totally sure which parameters you are
talking about. ROHC has a few parameters that must be agreed
between compressor and decompressor. These are the "Per-channel
parameters" listed in RFC3095 section 5.1.1, i.e. MAX_CID,
LARGE_CIDS, PROFILES supported, MRRU, and optionally FEEDBACK_FOR.
How these are configured/negotiated depends on the actual link
technology, where RFC3241 (ROHC-over-PPP) is a good example of
how such a negotiation can be defined.

RFC3095 (section 6.3) also lists a number of parameters suggested
as useful in an interface to a ROHC compressor or decompressor.
It should be noted that these parameters are for configuration
of a ROHC compressor OR decompressor, thus not subject to
negotiation. Remember also that the parameters listed are just
suggestions, an implementation might implement a subset of these,
an extended parameter set, or completely different parameters.
Which parameters that are useful depend of course on the actual
link technology the implementation is supposed to be used in.

Regarding your uplink/downlink question, I think that it is a
different question. RFC3095 does not consider specific link
integration, e.g. wireless links (as in your question).
For RFC3095, bi-directional communication (i.e. the fact that
you have both an "uplink" and a "downlink") has not in principle
affect the standard. RFC3095 defines how to do compression from
a compressor to a decompressor, and thus each direction 
corresponds to its own ROHC configuration. In your example, 
the downlink configuration is totally independent of the
uplink configuration, from an RFC3095 point of view. However,
this is of course a matter of how ROHC is integrated in the 
actual link technology, i.e. in the "ROHC-over-whatever"
standard applicable to your case. Note that the IETF ROHC WG
only defines ROHC-over-PPP, integration into other link
technologies must be addressed in other standard bodies.

> Second, I wonder if it's possible to have several streams
> for one service at the same time.

ROHC can handle a certain number of concurrent packet streams,
depending on how ROHC is configured over the channel, i.e. 
whether large or small CID's are used. Small CID allows 16
concurrent streams, while large CID can support up to 16383.
With streams, we mean any packet stream compressed by a
ROHC profile, including "non-compressed" sent with ROHC
profile 0x0000.

Then, as usual, the actual link technology and implementation
restrictions might affect these limits.

Regards.
/Lars-Erik

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 3 Sep 2002 09:55:08 +0200

SoYoung,

> Let's assume just a streaming service over ROHC (i.e 
> asymmetric bi-directional communication).
> Then, one way(DL) is used for RTP (multimedia data), and of 
> course,the other way(UL) is used for RTCP (RTP control information).

The number of CID's IN USE for each direction depends on the number of
concurrent packet streams over the channel in that direction. The CID
SPACE must be large enough to handle the possible number of streams.

A stream for RTP is usually defined as having constant:
- IP source and destination addresses
- UDP ports
- RTP SSRC

How many streams that will be generated for your streaming service
may of course differ. For example, the media combination and the way
the application(s) transmits data affect the number of RTP streams.
Note also that RTCP might be sent by both sender and receiver.

Remember that the number of actual streams matches the number
of CID's in use on each simplex ROHC channel, while the number of
possible CID's is pre-negotiated on the channel, either small (max 16
CID's) or large (max 16383). The former is about current "state" of 
application "connection", while the latter is a bout link capabilities.

> But, what I want to know is that if it's possible a RTP 
> session (for example, Video or multimedia data) 

Sure they can, but that is a matter of application design. If you have
a combination of various media, you will probably have several
concurrent RTP streams.

> (I think a "channel" in RFC3095 means a session. Am I right? )

I do not know what you mean with a session. For ROHC, a channel
is a logical L2 connection on top of which a ROHC instance is
running. That is thus a "link property" and not directly related to 
for example application sessions. 

> In this case, is there only one RTCP or several RTCPs for each stream?

Please refer to RFC 1889 (bis), and direct RTP related questions to
the AVT list.

BR
/Lars-Erik