Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompressi on

From: Majumdar Ishita-QA4906 <[email-masked]>
Date: Mon, 20 Aug 2001 12:20:26 -0500

Hi,

How about we start with 9.6 kbps both uplink and downlink and use  UMTS
frames to estimate the call set up delay? We can then slowly progress to
14.4 kbps and then 144 kbps to have a comparative analysis between
compression ratios and faster channels? After that we can incorporate
processing delays/queueing delays at both sender and receiver assuming one
is a Mobile and the other is a P_CSCF.

As I said with TCCB, the compression ratio improves with each successive
call between the same user agents. 

Here are some suggestions of scenarios.and performance parameters.
a) User A calling User B  (compression ratio, call et up delay improvement)

b) User A receiving a call from User C
c) User A calling User B (again)

In order to do the delay analysis, we not only have to use the same scenario
but also be sure that we use the same Protocol stack as specified in the
3GPP docs so that we add the correct header size to tha application layer
messages for all the successive layers beneath. Also it would be interesting
to know just how much more gain we get with SIP compression +UDP/IP  header
compression.

I could provide the numbers probably by Thursday so we can have a rough idea
what the numbers look.

Comments are welcome.

Thx,
Ishita

-----Original Message-----
From: Hans Hannu [mailto:[email-masked]]
Sent: Monday, August 20, 2001 11:46 AM
To: 'Lawrence Conroy'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression

Hi,

I like the idea of having some defined scenarios to be able to compare the
scheme against and those scenarios could be included in the requirements
document, but perhaps not under the requirements section, but under the
"assumptions" section.

We have already some message sequences (thanks to Richard and Ishita) that
we could use. What we need to do now is just find out some representative
channel bitrates to run these against. Maybe someone could provide some
channel bitrates?

Are there other "message exchange sequences" that someone thinks are more
representative than those already used?

BR
/Hans H

> >Hi Hans,
> >
> >Since the SIP Call set up latency is one of the main (if not
> the main)
> >problem we want to solve with signaling compression, I
> propose we add a
> >requirement to that effect:
> >
> >The compression scheme MUST be such that when applied to
> SIP, the call
> >set up latency is less than X seconds, for a representative set of
> >scenarios to be defined. Scenarios specify the messages
> exchanged, their
> >contents, as well as the channel bit rates.
> >
> >We need to agree on X and the scenarios, but I believe this
> requirement
> >is useful, because compression ratio alone does not
> adequately capture
> >the problem of call set up latency. Scenarios can be based on those
> >typically envisioned in cellular cases like 3GPP.
> >
> >Khiem
> >
> To which I reply:
> Hi Folks,
>    There is a GERAN meeting at the end of the month, and I will canvas
> to see if there is a HARD limit such as that proposed as a
> requirement.
>
> However...
> I think that the assumption that the main goal of SIP Comp is
> to reduce
> (or, as described above, =>LIMIT<= ) the call set up time is
> not obvious
> (to me, at least) and I'm not yet happy to have it included in the
> requirements document as proposed.
>
> For GERAN at least, the HARD requirement is on the mid-call Re-Invite
> sequence, NOT on the call set up. That's probably true for
> UTRAN as well,
> but that's not my area of interest.
>
> I have already sent a posting on my understanding of the
> GERAN mid-call
> problem and the figures that seem to apply there (and the reasons).
>
> Of course one benefit of SIP Comp is that we reduce the transmission
> time for messages sent during call set up for latency reasons, and so
> we may avoid too many re-transmissions of SIP messages.
> However, I don't
> see how this is a HARD requirement and would be interested in
> understanding
> the logic here.
>
> Do we have a specific limit (like the DCS one that is, I
> believe, regulated
> by the FCC)?
>
> BR,
>   L.
> --
> [email-masked]: +44 1794 833666::<my opinions>:
>

---
Mailing list for Robust Header Compression WG
Archive: http://www.cdt.luth.se/rohc/

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip