Subject: RE: Re:2.5g/3g ID additions (RE: pilc minutes (corrected))

From: "Farid Khafizov" <[email-masked]>
Date: Fri, 25 Jan 2002 02:39:25 -0600

Dear all:

We would  like to clarify a few things about our previous correspondence.

We believe this forum is not a place for deciding which 3G wireless
technology 
is better and this definitely was not our intention. This forum should be
objective and not biased 
towards any technology. We have no reason to think that CDMA2000 is inferior
to UMTS. 
If the proposed text implies that, as some have suggested, we must make
necessary changes to the text. 

Furthermore, it was not our intention to say or imply that Bandwidth
Oscillation
is *characteristic* of any particular network. This should be emphasized in
the text.
In the proposed text referring to UMTS and/or CDMA2000 we never say *will*.
Specifically discussing bandwidth oscillation, we say "may" or "can".
Like in UMTS, there are various ways to avoid bandwidth oscillation in
CDMA2000. 
That is why it was decided to address this issue in LINK ID.
We used CDMA2000 only as an example. UMTS could have been picked as an
example too,
if someone does "periodic switch between a high speed dedicated and the
common channels. " 

2.5g/3g ID is addressing issues of the networks that have not been widely
deployed. 
Initial field reports from operators do not look very rosy. Doing a search
on the web would show 
that expectations for 3g wireless data speed are much lower than originally
thought.
At this point it is reasonable to say that we do not know *all* TCP issues
related to 3g wireless. 
Only time will show what they are and how to address them. In the absence of
data from 
live networks with multiple users, one has to make certain assumptions on
how those network 
might operate and draw conclusions based on those assumptions.

IS-2000.5 specifies 14 options for finite Duration Supplemental Channel
assignment.
When we evaluated TCP performance for some of those options, we found that
TCP didn't like them.
It is true that vendors and/or operators may choose different
configurations.
However, it is important to realize that choosing a "better" SCH duration
may come at the
cost of additional signaling in the network which has implications to
interference limited capacity. 
If you consider scheduling of users (especially with different QoS classes)
, the problem becomes 
more complex. Even in "properly" designed sub-networks, admitting more users
means 
more revenue, but also increases likelihood of bandwidth oscillation. So, an

operator might still be interested in choosing non-optimal configuration
options (allowed by the standards)
as long as he can reduce throughput degradation by optimizing TCP.
That is the main reason why we think bandwidth oscillation should be
addressed in 2.5g/3g ID.

At this point, we can either remove the Bandwidth Oscillation text from the
draft and
pretend that it may never happen , or we can specifically state that 
Bandwidth Oscillation is a potential problems which MIGHT show up and 
offer TCP optimization techniques. 

--Farid

> -----Original Message-----
> From:	Andrei Gurtov [SMTP:[email-masked]]
> Sent:	Friday, January 25, 2002 12:42 AM
> To:	Kamesh Medepalli; Behcet Sarikaya
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected))
> 
> I agree that the problem of 'bandwidth oscillation' itself is not new.
> While
> not saying anything on cdma2000 vs. umts, I think we should not be so
> negative about this draft. The authors have done a very good job for
> example
> by experimenting on how existing different TCP implementations react to
> this
> type of RTT changes, evaluating the effect of different TCP features like
> timestamps or restarting the retransmit timer on ACKs.
> 
> After all, the final product is as good as its implementations and there
> was
> certainly something to learn for vendors and operators from this draft.
> Again, not saying that this is a good way to do the resource allocation...
> 
> Andrei/
> Sonera
> 
> ----- Original Message -----
> From: "Kamesh Medepalli" <[email-masked]>
> To: "Behcet Sarikaya" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, January 24, 2002 6:19 PM
> Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected))
> 
> 
> > I am not sure why the CDMA2000 ID was even considered seriously. It is
> > standard problem that needs to be addressed carefully at the MAC layer.
> > I am surprised folks actually went up to writing something like this
> > and blaming it on CDMA2000 in a way! Standards define the basic MAC
> > protocol. It is upto the Vendors to design "algorithms" for resource
> > allocation.
> >
> > What happened to Phil Karn's and Gorry's comments which were raised very
> > early after the initial draft was sent out?
> >
> > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such
> > problems to arise if someone used Downlink Shared Channel (DSCH) in UMTS
> > in a random manner..ofcourse dedicated channels (DCH) help.
> >
> > I hope others in the mailing list raise their voice too!
> >
> > Thanks Behcet!
> > Kamesh
> >
> > Behcet Sarikaya wrote:
> > >
> > > Dear all,
> > >   I am forwarding the opinion of Francois Courau from
> > > Alcatel France (who is the head of 3GPP RAN WG) on
> > > this issue.
> > >   I wish we could get another expert opinion of
> > > someone from Lucent or Qualcomm on  the situation in
> > > CDMA2000. I am afraid if we include Farid's text only
> > > for CDMA2000 this will cause problems as to the
> > > inferiority of CDMA2000 vis-a-vis UMTS.
> > >
> > > Regards,
> > >
> > > --behcet
> > >
> > > --- [email-masked] wrote:
> > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc
> > > > minutes (corrected))
> > > > To: Behcet Sarikaya <[email-masked]>
> > > > From: [email-masked]
> > > > Date: Thu, 24 Jan 2002 11:18:44 +0100
> > > >
> > > >
> > > > I fully share the analysis proposed by Ericsson. The
> > > > oscillation will be
> > > > linked with the reduction of throughpur decided
> > > > uponn by the radio access
> > > > network in the other cases we don't have a similar
> > > > problem to CDMA 2000.
> > > >
> > > > Francois
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Great stuff seeking new owners in Yahoo! Auctions!
> > > http://auctions.yahoo.com
> >
>

---

From: Kamesh Medepalli <[email-masked]>
Date: Fri, 25 Jan 2002 11:06:59 -0500

Farid, Andrei:

If the experiments are applicable to various technologies, my suggestion at 
this point is to create a subsection in either the 2.5g3g ID and/or LINK ID. 
It should first unambiguosly state that the problem is quite general and it 
exists in both wireless and wireline systems. Then as a specific example, 
describe why it is possible in GPRS, UMTS and CDMA-2000 2.5g3g Technologies.

After the description, mention the experiments, results and recommendations
(if any). Be sure that the results and recommendations apply across 
technologies. If they do not, there should be no additions made either
of the drafts based on your material - at this time. If you do not have
sufficient evidence to prove the general applicability of the solutions,
we should wait for the study to be completed. Good results should always
be published and I appreciate your willingness to do that.

Recommendations should be general. Otherwise, it doesn't make sense to 
highlight the issue by considering "one of the possible systems" and then 
proposing the solution for "that particular system". This issue gets a lot 
more tricky when you start dealing with 3G technologies. I believe you 
agree with those thoughts.

Thanks,
Kamesh

Farid Khafizov wrote:
> 
>    Part 1.1Type: Plain Text (text/plain)
Dear all:

--Farid

---

From: Aaron Falk <[email-masked]>
Date: Fri, 25 Jan 2002 11:53:43 -0800

Kamesh-

I think I disagree.  The results Farid has shown apply to CDMA2000 systems.
The purpose of the 2.5g3g document is to explain how operators can
configure TCP stacks to get good performance over these links.  I think it
is very appropriate to mention ameliorative techniques such as those
described in draft-khafizov-pilc-cdma2000-00.txt and in the proposed 2.5g3g
text.  Naturally, it is important to clarify which systems and MAC
configurations are addressed.  It is probably also appropriate to state
that this is an early research finding.  However, if there are real systems
deployed -- or planned to be deployed -- that have these problems, it is
appropriate to include this text in the 2.5g3g draft.

As we discussed in SLC, LINK also needs some text.  This text, as you
suggest below, should discuss the general problem of varying link
bandwidth.  The plans are to extend the section on 'Bandwidth on Demand' to
include these effects.  However, the purpose of LINK is to advise designers
of future links on things they should do -- or avoid doing -- to support
Internet.  It would not be appropriate to discuss how to tweak a TCP stack
to get good performance over a CDMA2000 link in this document.
*References* to Farid's work are worth including in LINK as warnings to
link designers of the negative consequences of link bandwidth oscillation
on TCP performance.

I hope this helps,

--aaron

--On Friday, January 25, 2002 11:06:59 AM -0500 Kamesh Medepalli
<[email-masked]> wrote:

> Farid, Andrei:
> 
> If the experiments are applicable to various technologies, my suggestion
> at  this point is to create a subsection in either the 2.5g3g ID and/or
> LINK ID.  It should first unambiguosly state that the problem is quite
> general and it  exists in both wireless and wireline systems. Then as a
> specific example,  describe why it is possible in GPRS, UMTS and
> CDMA-2000 2.5g3g Technologies.
> 
> After the description, mention the experiments, results and
> recommendations (if any). Be sure that the results and recommendations
> apply across  technologies. If they do not, there should be no additions
> made either of the drafts based on your material - at this time. If you
> do not have sufficient evidence to prove the general applicability of the
> solutions, we should wait for the study to be completed. Good results
> should always be published and I appreciate your willingness to do that.
> 
> proposing the solution for "that particular system". This issue gets a
> lot  more tricky when you start dealing with 3G technologies. I believe
> you  agree with those thoughts.
> 
> Thanks,
> Kamesh
> 
> Farid Khafizov wrote:
>> 
> towards any technology. We have no reason to think that CDMA2000 is
> inferior to UMTS. 
> is *characteristic* of any particular network. This should be emphasized
> in the text.
> In the proposed text referring to UMTS and/or CDMA2000 we never say
> *will*. Specifically discussing bandwidth oscillation, we say "may" or
> "can". Like in UMTS, there are various ways to avoid bandwidth
> oscillation in CDMA2000. 
> that expectations for 3g wireless data speed are much lower than
> originally thought.
> Only time will show what they are and how to address them. In the absence
> of data from 
> If you consider scheduling of users (especially with different QoS
> classes) , the problem becomes 
> more complex. Even in "properly" designed sub-networks, admitting more
> users means 
> At this point, we can either remove the Bandwidth Oscillation text from
> the draft and
>> > What happened to Phil Karn's and Gorry's comments which were raised
>> > very early after the initial draft was sent out?
>> > 
>> > problems to arise if someone used Downlink Shared Channel (DSCH) in
>> > UMTS in a random manner..ofcourse dedicated channels (DCH) help.
>> >

---

From: Kamesh Medepalli <[email-masked]>
Date: Fri, 25 Jan 2002 16:58:57 -0500

Aaron:

 Thanks for the mail.  A couple of comments:
 1. Wireless community is far different than Internet community. I don't have
    to tell you about all those Standards wars. Although CDMA-2000 ID has 
    recommendations backed by some experimental studies, it is for some
    examples of rate allocation. It is not a generic statement. If we do not
    change the wording/content, it is very easy for someone in Wireless to 
    say.."Oh, cdma2000 is not very TCP friendly, Where as UMTS, HDR 
    (1X-EV-DO), GPRS are" --- That is WRONG. All these systems need TCP fixes 
    if the resource allocation is not TCP friendly. The solution to the problem 
    is to fix the allocation scheme and let TCP be transparent. Each Vendor 
    has their own way of fixing this and operator ultimately chooses the one 
    which works the best! 
 2. It is not always possible for bandwidth oscillation to exist in CDMA-2000.
    Hence, the study cases in Farid's ID are kind of "specific examples". We 
    have worked for the last 3 years on HTTP,FTP/TCP over CDMA-2000 and hence 
    I can tell you that much! If anyone is interested, they can look at our
    VTC-2000 Spring paper (on just TCP) or MMT-2000 (with HTTP also) one. 
    These for static rates. A more comprehensive paper is being published 
    in Wireless Networks Journal [they haven't given us a date yet].

 If the recommendations are generic for all Wireless Schemes, then they
 should be included in an RFC. Otherwise, we should hold on or explain
 the problem and fixes with a "generic" tone..without highlighting 
 cdma2000 alone.

Thanks,
Kamesh

---

From: Kamesh Medepalli <[email-masked]>
Date: Fri, 25 Jan 2002 17:49:02 -0500

Hi Aaron:

Some comments inline..

Aaron Falk wrote:
> 
> > If we do not change the wording/content, it is very easy for someone
> > in Wireless to say.."Oh, cdma2000 is not very TCP friendly, Where as
> > UMTS, HDR (1X-EV-DO), GPRS are" --- That is WRONG. All these systems
> > need TCP fixes if the resource allocation is not TCP friendly. The
> > solution to the problem is to fix the allocation scheme and let TCP
> > be transparent. Each Vendor has their own way of fixing this and
> > operator ultimately chooses the one which works the best!
> 
> I think the doc should say (based on Farid's work) that this behavior is of
> specific concern to CDMA2000 networks because there is an increased
> liklihood of a MAC configuration which exhibits it.  Do you disagree that
> this is the case?

Yes.

> 
> >  2. It is not always possible for bandwidth oscillation to exist in
> > CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific
> > examples".
> 
> Can you give specific counter examples?

Sorry, I can't do it! (It may sound funny but such information is deemed
proprietary)

> 
> > We have worked for the last 3 years on HTTP,FTP/TCP over
> > CDMA-2000 and hence I can tell you that much! If anyone is
> > interested, they can look at our VTC-2000 Spring paper (on just TCP)
> > or MMT-2000 (with HTTP also) one.
> 
> URLs would be helpful here.
> 
> > These for static rates.
> 
> Um, bandwidth oscillation = dynamic rates != static rates, right?  Do these
> references address the issue we discussing or are you supporting your claim
> to be knowledgeable in the field?

No, these references do not show counter evidence. It is some proof that
we have worked on TCP over cdma2000! 

> So, as a non-expert in this area I'm still fuzzy about whether
> 
> a) there are significant examples of CDMA2000 MACs which do not exhibit
> bandwidth oscillation (i.e., can this be fixed with proper MAC tuning)?

My answer is Yes. Even Farid has commented on this to some extent, I am 
pasting his comments from the previous mail...
IS-2000.5 specifies 14 options for finite Duration Supplemental Channel
assignment.
When we evaluated TCP performance for some of those options, we found that
TCP didn't like them.
It is true that vendors and/or operators may choose different
configurations.
However, it is important to realize that choosing a "better" SCH duration
may come at the
cost of additional signaling in the network which has implications to
interference limited capacity. 
If you consider scheduling of users (especially with different QoS classes)
, the problem becomes 
more complex. Even in "properly" designed sub-networks, admitting more users
means 
more revenue, but also increases likelihood of bandwidth oscillation.

> 
> b) the type of bandwidth oscillation which affects TCP performance is also
> present in other 2.5g/3g systems.
> 
> I'd like to hear some more voices here.

I would like to also!

Thanks,
Kamesh

---

From: Aaron Falk <[email-masked]>
Date: Fri, 25 Jan 2002 14:30:17 -0800

Thanks,

--aaron

---

From: Kamesh Medepalli <[email-masked]>
Date: Fri, 25 Jan 2002 18:27:18 -0500

Aaron:

 I cannot make any more comments. I am for the last comment you made about
 crafting the text. I would be happy if the references to cdma2000 are kept
 to a minimum.

Thanks,
Kamesh

Aaron Falk wrote:
> 
> >> I think the doc should say (based on Farid's work) that this behavior is
> >> of specific concern to CDMA2000 networks because there is an increased
> If you want to convince me you'll have to support your answer with
> something more than that.  Farid has shown that there are modes in CDMA2000
> which exhibit bandwidth oscillation that can degrade TCP performance.
> Reiner has stated that this isn't the case for WCDMA/UMTS because of a
> different time scale used for the bandwidth allocation.  Please provide
> your reasoning why you feel that CDMA2000 isn't more likely to experience
> these problems.  I'm open minded about this but you have to back up your
> claim.
> 
> So you are aware of a proprietary solution that doesn't exhibit these
> problems.  Thats fine. (Actually, it's good!)  But because you (or your
> employer) feels its proprietary, that's even more indication that there may
> be/are people out there fielding systems which *do* exhibit these
> oscillations.  This text is for them.  I think Farid's text that you pasted
> below:
> 
> > assignment. When we evaluated TCP performance for some of those options,
> > we found that TCP didn't like them. It is true that vendors and/or
> > operators may choose different configurations. However, it is important
> > to realize that choosing a "better" SCH duration may come at the cost of
> > additional signaling in the network which has implications to
> > interference limited capacity. If you consider scheduling of users
> > (especially with different QoS classes) , the problem becomes more
> > complex. Even in "properly" designed sub-networks, admitting more users
> > means more revenue, but also increases likelihood of bandwidth
> > oscillation.
> 
> can be crafted into a suitable caveat that doesn't imply that all CDMA2000
> systems have worse performance than other technologies.
> 
> --aaron

---

From: Aaron Falk <[email-masked]>
Date: Fri, 25 Jan 2002 15:21:43 -0800

--aaron

---

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 26 Jan 2002 19:42:03 -0800 (PST)

Dear all,
> offer TCP optimization techniques. 

I vote for the former.

Regards,

--behcet