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
Aaron Falk wrote:
>
> 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
> <medepalli@lucent.com> 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.
> >
> > 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:
> >
> > 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:gurtov@cs.Helsinki.FI]
> >> Sent: Friday, January 25, 2002 12:42 AM
> >> To: Kamesh Medepalli; Behcet Sarikaya
> >> Cc: pilc@grc.nasa.gov; francois.courau@alcatel.fr
> >> 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" <medepalli@lucent.com>
> >> To: "Behcet Sarikaya" <sarikayab@yahoo.com>
> >> Cc: <pilc@grc.nasa.gov>; <francois.courau@alcatel.fr>
> >> 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
> >> > >
> >> > > --- Francois.Courau@alcatel.fr wrote:
> >> > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc
> >> > > > minutes (corrected))
> >> > > > To: Behcet Sarikaya <sarikayab@yahoo.com>
> >> > > > From: Francois.Courau@alcatel.fr
> >> > > > 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
> >> >
> >>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:28 EST