ietf-openproxy
[Top] [All Lists]

RE: User Profile Information Protocol

2001-03-08 00:24:39
Hi Phil,

I finally found time to answer this..If you want to continue this discussion
we should do it offline so not to clog people's mailbox.

comments inline...


-----Original Message-----
From: Phil Rzewski [mailto:philr(_at_)inktomi(_dot_)com]
Sent: Monday, March 05, 2001 4:31 PM
To: Reinaldo Penno; cdn(_at_)ops(_dot_)ietf(_dot_)org; 
ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: User Profile Information Protocol

Hi Reinaldo. I had read this and the companion draft a while back. It's
probably a good time for me to float my comments. :)

yeah, just after I commented your draft (:)

I noticed you posted to multiple lists, and indeed, my first comment is
that I'm not really sure where this belongs in the IETF landscape. It has a
CDI flavor because it mentions surrogates and these surrogates are likely
to be in a different administrative domain from the access device that
sends the information about user profiles. However, since the "different
administrative domains" isn't a requirement, it could also be a WEBI thing.
Also, since these profiles are largely going to determine the nature of
personalized services performed by the surrogates, that makes me think OPES.

I actually agree. I think  I should propose a BOF on personalization or
something similar.
I was reading "Example Services for Network Edge Proxies" and UPIF would
allow many of these services to come true.
http://search.ietf.org/internet-drafts/draft-beck-opes-esfnep-01.txt


My main technical question is regarding scalability. Imagine today's CDN
landscape where CDNs have thousands of surrogates. Does each surrogate need
to know about the profiles of all access users everywhere? Of course, we'd
think it logical that they only need to know about the profiles of users
that are "close" to those surrogates, but part of the benefit of CDNs in
handling "flash crowds" and such is that a far-away surrogate may be chosen
in lieu of a nearby, congested one.

If you thinking about redirection, the UPIF would be running on a traffic
interception device (TID). Anyway, just because a local surrogate/TID knows
your profile that doesn't mean you cannot be redirected to a far-away (but
better at this point in time). On the other hand, if you are a premium I'll
make sure you also have room (in terms of bandwidth, disk space, whatever)
in relation to other users. In this case a flash crowd premium user (in lack
of a better term)  could preempt (in terms of resources) a user in the local
surrogate. This is "normal" user then would be redirected to a far away
cache (even it it's not the better).

Our CDI model may imply that the
profiles would be handed off to one "gateway" of each CDN and the CDN would
distribute it to surrogates as necessary. However, I don't think it's fair
to say "you handle it internally" to the CDNs if we know up front that it's
a problem that's difficult/impossible to scale (each CDN conceivably having
millions of profiles on every surrogate).

UPIF was designed to work with surrogate, proxies or traffic interception
devices. You can run it on traffic interception devices only and use the
profile information on surrogates just enahnce accouting.

thanks for the comments,

Reinaldo



<Prev in Thread] Current Thread [Next in Thread>