W3C home > Mailing lists > Public > www-mobile@w3.org > November 2001

RE: CC/PP profile repository overworked?

From: Butler, Mark <Mark_Butler@hplb.hpl.hp.com>
Date: Thu, 22 Nov 2001 09:57:28 -0000
Message-ID: <5E13A1874524D411A876006008CD059F031A1338@0-mail-1.hpl.hp.com>
To: www-mobile@w3.org
RE: Keio

Well to say they "proved" it is a bit strong - they provided experimental
evidence for this by running a simulation. Just in case anyone is interested
the graphs are available at 

http://yax.tom.sfc.keio.ac.jp/panda/slidemaker/0011ccpp/slide10-0.html

As far as I can see they support my point of view: i.e. when optimizing
retrieval time, caching at the origin server is more efficient than caching
at the gateway and that for large profiles external references are better
than inline encoding. However as the size of the profile-diff relative to
the original profile increases, it becomes increasingly preferable to use
inline profiles as this will decrease request sizes. 

If anyone has a URL for the original paper I would be interested to see it?

regards

Mark H. Butler
Research Scientist
HP Labs Bristol

-----Original Message-----
From: Johan Hjelm [mailto:johan.hjelm@era-t.ericsson.se]
Sent: 21 November 2001 23:42
To: Butler, Mark
Cc: 'Suryanarayana, Lalitha'; www-mobile@w3.org
Subject: Re: CC/PP profile repository overworked?


Keio University proved that the profile caching made the data transfer
considerably more efficient in their SASA implementation, in the paper
presented
at MDM'01.

Johan

"Butler, Mark" wrote:

> Lalitha
>
> Firstly I regard these as implementation issues rather than issues that
> require changes to the specification as they are primarily concerned with
> efficiency.
>
> My concern is although it is legal for requests to omit profile
references,
> if they do then the origin server cannot cache profiles, reducing the
> efficiency of the origin server. Note when I say caching I mean the
> reference profile, not the profile diff. If servers cache the reference
> profile, they can still cope with turning the sound off or changing
location
> as you describe. Caching by the origin server is not mandated by the
> standard but currently I think it is one way of improving efficiency - see
> my implementation for more details. If someone can explain why it is a bad
> idea or a better approach then let me know - comments or criticisms on my
> implementation are very welcome.
>
> If caching is done at the gateway this also reduces load on the profile
> repository. However as Nick points out this dramatically increases the
size
> of HTTP request headers, which could adversely effect network performance,
> and the gateway supplier has to support this as it's not mandated by the
> standard.
>
> Also, just to confirm, I've tested DELI and it can cope with requests that
> omit profile references - see the test plan distributed with the source
code
> for more details.
>
> best regards
>
> Mark Butler
> Research Scientist
> HP Labs Bristol
>
> -----Original Message-----
> From: Suryanarayana, Lalitha [mailto:lalitha@tri.sbc.com]
> Sent: 21 November 2001 16:00
> To: 'Butler, Mark'
> Cc: www-mobile@w3.org
> Subject: RE: CC/PP profile repository overworked?
>
> Mark:
>
> I do not think I understand your concern. The original intent was to be
able
> to support the ability to send the profile on every request although the
> expectation was that implementors would use the caching mechanisms etc.
The
> rationale was the potential likelihood of changes to the profile CPI in
> between 2 requests (eg location or someone turning sound on or off, etc).
>
> The headers look fine to me.
>
> When in doubt I would look at http://www.w3.org/TR/NOTE-CCPPexchange as a
> basis, even for the x-wap-profile and x-wap-profile-diff headers.
>
> Regarding your other note on RDF on the UAProf mailing list, I noted that
> Johan has forwarded it to the W3C group, which is the right place for the
> issue to be discussed.
>
> Lalitha
>
> -----Original Message-----
> From: Butler, Mark [mailto:Mark_Butler@hplb.hpl.hp.com]
> Sent: Tuesday, November 20, 2001 9:08 AM
> To: 'eizdepski@cysive.com'; nick.denny@mci.co.uk
> Cc: www-mobile@w3.org
> Subject: RE: CC/PP profile repository overworked?
>
> Erich's absolutely right - reading the UAProf specs, section 9.1.1.1 page
38
>
> "The x-wap-profile header is a general header field which must contain the
> following:
> - a URI referencing the CPI or
> - a reference to a profile difference, transported using the
> x-wap-profile-diff or
> - a combination of multiple instances of these two types of data."
>
> This means headers of the following form are legal:
>
> GET /ccpp/html/ HTTP/1.1
> Host: localhost
> x-wap-profile:"1-Rb0sq/nuUFQU75vAjKyiHw=="
> x-wap-profile-diff:1;<?xml version="1.0"?>
>  <rdf:RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">
>   <rdf:Description rdf:ID="MyDeviceProfile">
>      <prf:component>
>        <rdf:Description rdf:ID="HardwarePlatform">
>           <rdf:type
>   rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-
>     20010426#HardwarePlatform"/>
>                 <prf:BitsPerPixel>16</prf:BitsPerPixel>
> </rdf:Description>
>      </prf:component>
>   </rdf:Description>
>  </rdf:RDF>
>
> I hadn't realised this - I expect DELI will not parse such requests as it
> expects a profile reference. I'll note it as an issue to be fixed in the
> next release.
>
> However I think this is an inefficient way of working as it means the
> gateway must forward the entire reference profile to the origin server
with
> every request. It's more efficient for the origin server to cache the
> reference profile, but this can only be done with a profile reference.
> Therefore I would discourage the OpenWave folks (or anyone else) from
using
> this approach. Anybody else thought about this?
>
> For more information on DELI see http://www-uk.hpl.hp.com/people/marbut/
>
> Mark H. Butler
> Research Scientist
> HP Labs Bristol
>
> -----Original Message-----
> From: Erich Izdepski [mailto:eizdepski@cysive.com]
> Sent: 20 November 2001 14:20
> To: nick.denny@mci.co.uk
> Cc: www-mobile@w3.org
> Subject: RE: CC/PP profile repository overworked?
>
> The WAP gateway can (and I think openwave's will be soon) provide the
CC/PP
> profile to the origin server as a HTTP header. The gateway should be
> managing its own cache of profiles that it has collected from other
servers,
> in the ideal case. For now, there are no other servers providing CC/PP
data
> about device hardware or software, meaning the gateway has to have its own
> database of information. This is OK, it is simple for a gateway to create
> CC/PP data from a local database of phone/handheld information and
appended
> it to the device headers. I know the Openwave gateway already appends
header
> information about its fax capabilities, so adding a CC/PP profile is not a
> stretch.
>
> Erich Izdepski
>
> -----Original Message-----
> From: nick.denny@mci.co.uk [mailto:nick.denny@mci.co.uk]
> Sent: Tuesday, November 20, 2001 5:07 AM
> To: www-mobile@w3.org
> Subject: RE: CC/PP profile repository overworked?
>
> Hello again,
>
> Firstly thank you to Erich and Mark for your quick and helpful replies.
>
> Whilst reading the CC/PP requirements and architecture document
> (specifically section 2.2) I noticed that in the WAP implementation, the
> WAP gateway appears to resolve the profile URL and retreive the profile.
> Is this correct? And if so, what is the Origin Server sent? Is it the
> URL to the profile repository, in which case why does the WAP gateway
> have to resolve it? Or is it a URL to the cached information in the
> gateway?
>
> Many thanks,
>
> Nick Denny
> nick.denny@mci.co.uk

--
++++++++++++++++++++++++++++++++++++
  Johan Hjelm, Senior Specialist
     Ericsson Research Japan

  "Do you want to sell sugar water or
change the world" is the wrong question.
  The right question is: "How do you
change the world by selling sugar water?"

  Read more about my recent book
http://www.wireless-information.net
************************************
Received on Thursday, 22 November 2001 04:58:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:03 UTC