Subject: Re: [alto] The origins of the piracy debate...

From: Eric Burger <[email-masked]>
Date: Fri, 1 May 2009 08:48:50 -0400

I would also like to point out the mechanism described in Nicholas'  
original email, taking intelligent action based on the content ID, is  
something an ALTO Server *can* implement.  There is NOTHING so far  
proposed in ALTO that would prevent a server from somehow figuring out  
the request is likely to be a request for illegal content and then  
doing something about it.  However, such calculations occur at a layer  
*above* ALTO.

For that matter, I would offer that by NOT specifying such a content  
screening function in ALTO *enhances* the ability of service providers  
to detect illegal content requests.  Rather than baking in a mechanism  
that works today but is virtually guaranteed to be compromised  
tomorrow, we keep providers' options open to implement the latest,  
best countermeasures in the future.

On Apr 30, 2009, at 6:58 PM, Richard Bennett wrote:

> As long as ALTO is defined as a service that maps a content ID to a  
> collection of paths, it seems to me that it's piracy-neutral. I'm  
> disturbed by a system that is passed a collection of paths and asked  
> to rank them, as that would seem to have a definite pro-piracy bias.  
> But I agree with Nick (I think) that a system that accepts a  
> transient content ID and returns a list of paths is neither pro- 
> piracy or anti-piracy. The rights management function can be layered  
> on top of ALTO, as I think it should be, as a kind of DNS-for- 
> content that takes some sort of textual description of the content  
> and returns an identifier that ALTO can then use to guide toward the  
> best paths. The higher level function - the content mapper - can be  
> developed independent of IETF guidance and in accordance with some  
> sort of deal between content producers and network operators. The  
> content mapper is where the rights management goes, not in ALTO.
>
> RB
>
> Nicholas Weaver wrote:
>>
>> On Apr 30, 2009, at 2:19 PM, DePriest, Greg (NBC Universal) wrote:
>>
>>> Thanks to Enrico and Nicholas for providing additional background  
>>> and
>>> explanations.
>>>
>>> The key point of disagreement seems to be that adding a content
>>> protection requirement to ALTO would "hugely complicate and  
>>> compromise
>>> the design of
>>> ALTO."
>>>
>>> I'm not an expert in such matters, have very limited exposure to the
>>> area, and can't help but wonder if that is, in fact, correct.
>>>
>>> Was there a serious investigation or did someone simply do a
>>> back-of-the-envelope analysis.
>>
>> For me, its "Intuition backed up by a threat analysis and usage  
>> cases":
>>
>> We have legitimate uses which requires ID churn: its the only way  
>> to guarantee that a rebalancing is fresh.  Especially since nodes  
>> churn all the time, and ALTO may not have notification when nodes  
>> leave.
>>
>> We have legitimate uses which require IDs to be arbitrary (rather  
>> than representative hashes): ALTO is not just for file  
>> distribution, but other P2P optimization (eg, optimizing for low  
>> latency for DHTs) where hashes don't have meaning.  ALTO doesn't  
>> want to deal with particular P2P protocols, which all may have  
>> different representations of what data or blocks are.  And doesn't  
>> want to deal with colliding namespaces from different P2P  
>> programs.  Thus defining ID as a UUID or other opaque identifier  
>> means ALTO doesn't have to deal with these problems.
>>
>> We have legitimate uses which require IDs to be creatable at-will  
>> by any party:  Otherwise, ALTO becomes an admission only system  
>> which limits utility.
>>
>>
>> Yet all three decisions (allowing churn, opaque-data IDs, at-will  
>> ID creation) and there becomes an easy countermeasure to ANY system  
>> predicated on "block bad IDs", as long as that system has a slower  
>> response time than the P2P network you are trying to prevent  
>> optimizing its communication, and you can't do "only allow good  
>> IDs" if IDs are creatable at-will by any party.
>>
>> And "if a defense has a trivial countermeasure, don't bother  
>> deploying it".
>>
>> Thus this means the only way to make ALTO "content protecting" is  
>> to remove one of those three constraints.  But all three features  
>> are very valuable in a localization service.
>>
>>
>>
>> Additionally, there is a large bias in the network community in  
>> general to be "content neutral".  Any time you cease to be content  
>> neutral on the technical level, it must necessarily impose  
>> constraints and costs on the system.

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 1 May 2009 09:05:49 -0400

This makes sense.  Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Thursday, April 30, 2009 5:59 PM
To: DePriest, Greg (NBC Universal)
Cc: Paul Jessop; Nicholas Weaver; alto; [email-masked]
Subject: Re: [alto] The origins of the piracy debate...

On Apr 30, 2009, at 2:19 PM, DePriest, Greg (NBC Universal) wrote:

> Thanks to Enrico and Nicholas for providing additional background and
> explanations.
>
> protection requirement to ALTO would "hugely complicate and compromise
> the design of
> ALTO."
>

For me, its "Intuition backed up by a threat analysis and usage cases":

We have legitimate uses which requires ID churn: its the only way to  
guarantee that a rebalancing is fresh.  Especially since nodes churn  
all the time, and ALTO may not have notification when nodes leave.

We have legitimate uses which require IDs to be arbitrary (rather than  
representative hashes): ALTO is not just for file distribution, but  
other P2P optimization (eg, optimizing for low latency for DHTs) where  
hashes don't have meaning.  ALTO doesn't want to deal with particular  
P2P protocols, which all may have different representations of what  
data or blocks are.  And doesn't want to deal with colliding  
namespaces from different P2P programs.  Thus defining ID as a UUID or  
other opaque identifier means ALTO doesn't have to deal with these  
problems.

We have legitimate uses which require IDs to be creatable at-will by  
any party:  Otherwise, ALTO becomes an admission only system which  
limits utility.

Yet all three decisions (allowing churn, opaque-data IDs, at-will ID  
creation) and there becomes an easy countermeasure to ANY system  
predicated on "block bad IDs", as long as that system has a slower  
response time than the P2P network you are trying to prevent  
optimizing its communication, and you can't do "only allow good IDs"  
if IDs are creatable at-will by any party.

And "if a defense has a trivial countermeasure, don't bother deploying  
it".

Thus this means the only way to make ALTO "content protecting" is to  
remove one of those three constraints.  But all three features are  
very valuable in a localization service.

Additionally, there is a large bias in the network community in  
general to be "content neutral".  Any time you cease to be content  
neutral on the technical level, it must necessarily impose constraints  
and costs on the system.

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 1 May 2009 09:15:56 -0400

This also makes sense.

-----Original Message-----
From: Richard Bennett [mailto:[email-masked]] 
Sent: Thursday, April 30, 2009 6:58 PM
To: Nicholas Weaver
Cc: DePriest, Greg (NBC Universal); Paul Jessop; alto; [email-masked]
Subject: Re: [alto] The origins of the piracy debate...

As long as ALTO is defined as a service that maps a content ID to a 
collection of paths, it seems to me that it's piracy-neutral. I'm 
disturbed by a system that is passed a collection of paths and asked to 
rank them, as that would seem to have a definite pro-piracy bias. But I 
agree with Nick (I think) that a system that accepts a transient content

ID and returns a list of paths is neither pro-piracy or anti-piracy. The

rights management function can be layered on top of ALTO, as I think it 
should be, as a kind of DNS-for-content that takes some sort of textual 
description of the content and returns an identifier that ALTO can then 
use to guide toward the best paths. The higher level function - the 
content mapper - can be developed independent of IETF guidance and in 
accordance with some sort of deal between content producers and network 
operators. The content mapper is where the rights management goes, not 
in ALTO.

RB

compromise

---

From: "Y. R. Yang" <[email-masked]>
Date: Fri, 1 May 2009 12:36:15 -0400 (EDT)

Hi All,

I found the discussion related with content ID interesting.

Pushing upper layer information, in particular, content ID, into ALTO, 
according to my perspective, is to make it possible to turn an ALTO server 
into a session tracker so that it may take on additional potential 
functions (depending on the format of the content ID) including content 
discovery (e.g., discover popular contents, notify caches), peer discovery 
(e.g., allow caches to register availability, return peers that a 
requesting peer does not know but ALTO server knows), and load balancing 
(e.g., the discussion on re-balancing). This email thread is discussing 
about using it for rights management. I have no problem in adding an 
optional Content ID.

But we need to keep in mind that providing the aforementioned functions 
may lead to a substantially more complex ALTO server architecture and 
semantics. I am particularly not clear about the statement that it is 
better for ALTO to provide information in the context of a particular 
content/swarm/channel (identified by a content ID in an ALTO query). What 
is the semantics/meaning that the ALTO info returned is adapted to a 
particular content/swarm/channel? There can be many types of contents, 
e.g., file (BT block scheduling vs E2dk which uses a priority queue), live 
streaming, VoD, VoIP, game. Different applications/variants will have 
their specific requirements/secret sauce for constructing peer 
communication patterns. A query may be issued in a particular context, 
e.g., a seeder is looking for leechers or a leecher is looking for 
seeders. An application may use a lot more information (e.g., who are 
sources, who are seeders, upload/download capacity, buffer status, playout 
delay) to construct peer communication patterns. ALTO network information 
is just one of the many inputs. Are we talking about designing an 
omnipotent ALTO server that functions as a universal application tracker?

To make progress, follow the end-to-end design principle, and implement 
modular/reusable design, I feel that we should first design the most 
basic, reusable ALTO component, whose function is just to provide simple, 
useful network information service, which is likely to be content 
independent. Then we can talk about more extensions. Content protection 
(e.g., content ID as access control token), content discovery (e.g., 
mapping from a content ID to a list of servers), content notification to 
caches, cache integration, session tracking, peer selection should be 
independent services, should ALTO provide some of them. The protocols 
(e.g., ALTO/P4P InfoExport interface descriptor) I have seen so far are 
quite extensible to accommodate new services.

Richard

On Thu, 30 Apr 2009, 3:58pm -0700, Richard Bennett wrote:

> As long as ALTO is defined as a service that maps a content ID to a collection
> of paths, it seems to me that it's piracy-neutral. I'm disturbed by a system
> that is passed a collection of paths and asked to rank them, as that would
> seem to have a definite pro-piracy bias. But I agree with Nick (I think) that
> a system that accepts a transient content ID and returns a list of paths is
> neither pro-piracy or anti-piracy. The rights management function can be
> layered on top of ALTO, as I think it should be, as a kind of DNS-for-content
> that takes some sort of textual description of the content and returns an
> identifier that ALTO can then use to guide toward the best paths. The higher
> level function - the content mapper - can be developed independent of IETF
> guidance and in accordance with some sort of deal between content producers
> and network operators. The content mapper is where the rights management goes,
> not in ALTO.
> 
> RB
> 
> Nicholas Weaver wrote:
> >
> > guarantee that a rebalancing is fresh.  Especially since nodes churn all the
> > time, and ALTO may not have notification when nodes leave.
> >
> > representative hashes): ALTO is not just for file distribution, but other
> > P2P optimization (eg, optimizing for low latency for DHTs) where hashes
> > don't have meaning.  ALTO doesn't want to deal with particular P2P
> > protocols, which all may have different representations of what data or
> > blocks are.  And doesn't want to deal with colliding namespaces from
> > different P2P programs.  Thus defining ID as a UUID or other opaque
> > identifier means ALTO doesn't have to deal with these problems.
> >
> > We have legitimate uses which require IDs to be creatable at-will by any
> > party:  Otherwise, ALTO becomes an admission only system which limits
> > utility.
> >
> >
> > creation) and there becomes an easy countermeasure to ANY system predicated
> > on "block bad IDs", as long as that system has a slower response time than
> > the P2P network you are trying to prevent optimizing its communication, and
> > you can't do "only allow good IDs" if IDs are creatable at-will by any
> > party.
> >
> > And "if a defense has a trivial countermeasure, don't bother deploying it".
> >
> > Thus this means the only way to make ALTO "content protecting" is to remove
> > one of those three constraints.  But all three features are very valuable in
> > a localization service.
> >
> >
> >
> > Additionally, there is a large bias in the network community in general to
> > be "content neutral".  Any time you cease to be content neutral on the
> > technical level, it must necessarily impose constraints and costs on the
> > system.
> >

---

From: John Leslie <[email-masked]>
Date: Fri, 1 May 2009 13:41:51 -0400

Y. R. Yang <[email-masked]> wrote:
> 
> ... I am particularly not clear about the statement that it is better
> for ALTO to provide information in the context of a particular 
> content/swarm/channel (identified by a content ID in an ALTO query).
> What is the semantics/meaning that the ALTO info returned is adapted
> to a particular content/swarm/channel?

   Good question!

   An ALTO server run by the end-user's ISP should have good information
about network infrastructure (near the end-user, anyway), but does not
seem to me to be in any position to say whether any of the IP addresses
it returns would even provide the _same_ data in response to that
Content ID -- least of all the "right" data.

> There can be many types of contents, e.g., file (BT block scheduling
> vs E2dk which uses a priority queue), live streaming, VoD, VoIP, game.

   Et cetera... (An application I find interesting to consider is what
I call "Internet Talk Radio" -- basically one-to-many, but with no
predictability of content from minute to minute.)

> independent.

   I quite agree.

--
John Leslie <[email-masked]>

---

From: Eric Burger <[email-masked]>
Date: Fri, 1 May 2009 15:53:17 -0400

I think such a proposal would require a globally unique and time  
invariant content ID.  That sounds challenging at best.

On May 1, 2009, at 12:36 PM, Y. R. Yang wrote:

> What
>> collection
>>> than
>>> by any
>>> predicated
>>> to remove
>>> general to

---

From: "Y. R. Yang" <[email-masked]>
Date: Fri, 1 May 2009 15:57:39 -0400 (EDT)

Hi Eric,

On Fri, 1 May 2009, 3:53pm -0400, Eric Burger wrote:

> I think such a proposal would require a globally unique and time invariant
> content ID.  That sounds challenging at best.

I am not sure I am following. What requires a globally unique and time 
invariant content ID?

Richard
 
> > > >remove

---

From: Eric Burger <[email-masked]>
Date: Fri, 1 May 2009 16:05:29 -0400

I would expect that do do content discovery or peer discovery one  
would need a relatively fixed identifier for that content.

On May 1, 2009, at 3:57 PM, Y. R. Yang wrote:

>> invariant
>>>> of paths, it seems to me that it's piracy-neutral. I'm disturbed  
>>>> by a
>>>> system
>>>> seem to have a definite pro-piracy bias. But I agree with Nick (I  
>>>> think)
>>>> that
>>>> identifier that ALTO can then use to guide toward the best paths.  
>>>> The
>>>> higher
>>>> and network operators. The content mapper is where the rights  
>>>> management
>>>> goes,
>>>> not in ALTO.
>>>>
>>>> RB
>>>>
>>>> Nicholas Weaver wrote:
>>>>>
>>>>> guarantee that a rebalancing is fresh.  Especially since nodes  
>>>>> churn all
>>>>> the
>>>>> on "block bad IDs", as long as that system has a slower response  
>>>>> time
>>>>> than
>>>>> the P2P network you are trying to prevent optimizing its  
>>>>> communication,
>>>>> and
>>>>> deploying
>>>>> one of those three constraints.  But all three features are very  
>>>>> valuable
>>>>> in
>>>>> a localization service.
>>>>>
>>>>>
>>>>>
>>>>> general
>>>>> to

---

From: Jim Turner <[email-masked]>
Date: Fri, 1 May 2009 13:49:44 -0700

If I understand the concept of "content-id" correctly,
Van Jacobsen and his team at Xerox-PARC are working on such globally  
unique, time-invariant content identifiers as we speak...."google" for  
"content-centric networking"

Jim

On May 1, 2009, at 12:53 PM, Eric Burger wrote:

>>> by a system
>>> think) that
>>> The higher
>>> management goes,
>>>> churn all the
>>>> ID
>>>> time than
>>>> communication, and
>>>> valuable in

---

From: "Y. R. Yang" <[email-masked]>
Date: Fri, 1 May 2009 16:56:53 -0400 (EDT)

Absolutely agree. For a fixed file, some hash of the file content can 
serve as the globally unique identifier for that content. I believe that 
some "content integrator", which fetch the same content from multiple 
sources (e.g., http/ftp, BT, eMule, their own network), search and index 
contents across networks this way. Of course, this is not discovery of 
content, but discovery of a content of a particular encoding (e.g., same 
picture but one using jpg and the other png will not be considered as the 
same "content"). Do people know of other robust, scalable content 
discovery techniques?

Richard

On Fri, 1 May 2009, 4:05pm -0400, Eric Burger wrote:

> I would expect that do do content discovery or peer discovery one would need a
> relatively fixed identifier for that content.
> 
> > > > > >all
> > > > > >other
> > > > > >any

---

From: Satish Raghunath <[email-masked]>
Date: Sat, 2 May 2009 10:13:36 -0700

It is not clear to me why the ALTO service needs a content ID to aid something like content protection. (I take content ID to mean a unique identifier of the object that the client is trying to download.)

ALTO requirements already provide for authorized access to the ALTO service:

   REQ.  ARv00-27: The ALTO client protocol MUST support mechanisms for
   mutual authentication and authorization of ALTO clients and servers.

In the particular case of content protection, I can think of something like this:

                         |
                         |----> Future mechanisms
                         |
        +---------------+| Send req   +----------------+
        |               || ....>      | Content-aware  |
        |  ALTO client  |.............| services (like |
        |               |   <....     | protection)    |
        +-------+-------+  Get auth   +----------------+
                |         info + possibly
      ALTO proto|          peer list
                |
        +-------+---------+
        | ALTO server     |
        | conditions      |
        | service on auth |
        | information     |
        +-----------------+

All the ALTO service needs to be able to do is accommodate standards based authentication and authorization mechanisms. The provider of the ALTO service decides what a client with right credentials receives in responses and what other clients receive.

Thanks,
Satish

> Sent: Thursday, April 30, 2009 2:59 PM

---

From: Richard Bennett <[email-masked]>
Date: Sat, 02 May 2009 11:03:54 -0700

That's the way I see it as well.

RB

Satish Raghunath wrote:

|
|----> Future mechanisms
|

Thanks,
Satish

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 02 May 2009 16:58:49 -0400

I feel that it becomes increasingly difficult to follow the discussion 
on "content protection":

Q1: What "content" are we referring to?
Q2: What protection (attacks) are we referring to?

For Q1, I can see at least three types of contents:
 C1: Consumer content (e.g., Movie X);
 C2: Content availability information (e.g., servers A/B (peers D/E, or 
caches F/G) can provide (part of) Movie X);
 C3: Network information (e.g., the network path from A to C is good/bad).

Do I miss any other potential interpretations?

For protection, I assume we are referring to access control to 
aforementioned contents.

Realistically, I do not see how ALTO is in a position to protect C1. See 
HDCP to see
the complexity. Please correct me if I miss anything. It will be a quite 
challenging issue
and ALTO will be just one component in a much bigger picture.

It seems that we are referring to C2 and C3. Do I understand the 
situation correctly?

For C2, personally, I do not think it should belong to the *basic* ALTO 
services.
It is a content discovery mechanism. ALTO is not in a position to block 
existing
discovery mechanisms (e.g., DHT, tracker sites). It is debatable that it 
should belong
to ALTO, which is mainly focused on network/application interface, at 
least according
to my understanding.

For C3, it appears that we can do something so that ALTO does not help with
accelerating downloading of "illegal" content. For example, an ALTO server
provides C3 only to a subset of clients (or gives different 
information). The
selection of the subset is based on some access control policy. One 
possibility
is that a client presents some access token/credential (Satish's approach).
One issue is that who has the authority to issue the access credentials 
that can
be acceptable by an ALTO server. Remember that we are talking about a
large number of ALTO servers (e.g., one ALTO server for each ISP).
At the same time, I image that there can be many sources who can "voucher"
that a content (C3) is "legal" and the network should help. An alternative
is that access to C3 is based on a blacklist approach (default is allow, 
and
allows deny). But this also has substantial technique/trust/security 
challenges.

Clearly, "content protection" is not an issue that we (i.e., I) 
understand well.

Richard

Richard

Richard Bennett wrote:
> ------------------------------------------------------------------------
>

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Mon, 4 May 2009 13:35:37 -0400

Using your three categories of content, my concern is "C1: Consumer
content (e.g., Movie X)."  Of course, it's much broader than movies and
includes music, software, games, etc. -- essentially the copyrighted
content that's freely traded via P2P today without the copyright owner's
permission.  

I call it "content protection" while Richard Bennett calls it "rights
management." Others have suggested content creators simply need stronger
DRM.  None of these characterizations quite fits.

Let me explain:  Content creators are concerned with content that's gone
"into the wild" or "over the fence."  It could be a camcorded movie, a
DVD rip, or unprotected music.  

The issue isn't DRM for the content may or may not have been wrapped in
DRM originally (a camcorded movie would not be, for example).  And it's
not quite "rights management" as it's difficult to manage rights when
content is already freely available.  

What it is possible to do is to discriminate against pirated content and
that's my goal (denying ALTO access, e.g.).  

I'm not sure of your view other than on Friday you noted "I believe that
some 'content integrator' which fetch the same content from multiple
sources (e.g., http/ftp, BT, eMule, their own network), search and index
contents across networks this way."  

If "BT, eMule,..." are distributing pirated content, I would argue they
should not qualify for ALTO service. 

		*		*		*		*

Originally I thought hashes could be used to identify pirated content
and discriminate against it.  Nicholas points out that UUIDs are more
likely to be used at the lowest level for the reasons contained in his
response from last week.  

Satish noted that "All the ALTO service needs to be able to do is
accommodate standards based authentication and authorization mechanisms.
The provider of the ALTO service decides what a client with right
credentials receives in responses and what other clients receive."

Maybe that's right.  I'm not sure.  

The question that does come to mind is who operates the ALTO service?

In any event, did I answer your question?

-----Original Message-----
From: Y. Richard Yang [mailto:[email-masked]] 
Sent: Saturday, May 02, 2009 4:59 PM
To: Richard Bennett
Cc: Satish Raghunath; Paul Jessop; [email-masked]; Nicholas Weaver;
alto; DePriest, Greg (NBC Universal)
Subject: Re: [alto] The origins of the piracy debate...

 C3: Network information (e.g., the network path from A to C is
good/bad).

HDCP to see

challenging issue

should belong

For C3, it appears that we can do something so that ALTO does not help
with
accelerating downloading of "illegal" content. For example, an ALTO
server
provides C3 only to a subset of clients (or gives different 
information). The
selection of the subset is based on some access control policy. One 
possibility
is that a client presents some access token/credential (Satish's
approach).
One issue is that who has the authority to issue the access credentials 
that can
be acceptable by an ALTO server. Remember that we are talking about a
large number of ALTO servers (e.g., one ALTO server for each ISP).
At the same time, I image that there can be many sources who can
"voucher"
that a content (C3) is "legal" and the network should help. An
alternative
is that access to C3 is based on a blacklist approach (default is allow,

and

Richard

Richard

Richard Bennett wrote:
>> It is not clear to me why the ALTO service needs a content ID to aid
something like content protection. (I take content ID to mean a unique
identifier of the object that the client is trying to download.)
>> All the ALTO service needs to be able to do is accommodate standards
based authentication and authorization mechanisms. The provider of the
ALTO service decides what a client with right credentials receives in
responses and what other clients receive.
and
compromise
than
deploying
>>> neutral on the technical level, it must necessarily impose
constraints

---

From: Gyorgy Dan <[email-masked]>
Date: Mon, 04 May 2009 20:26:22 +0200

Greg,

Personally, I do not see why the approach
---
If "BT, eMule,..." are distributing pirated content, I would argue they 
should not qualify for ALTO service."
---
would be beneficial with respect to C1. My reasoning is the following, 
please correct me if I am missing something:

On the one hand, BT, eMule and all other applications are doing quite 
fine without the ALTO service today in the Internet: they can locate 
content and they can locate peers, unfortunately, mostly in a network 
unaware manner. Consequently, denying them access to the ALTO service 
would not make the distribution of illegal content impossible, probably 
not even more difficult.

On the other hand, if we believe the statistics that were quoted on this 
mailing list a few weeks ago (something like 99% or more of file sharing 
traffic
is illegal content) then excluding illegal content from the ALTO service 
will penalize the ISPs significantly (in case they are the ones 
operating the ALTO service), as most of the content will be distributed 
without any traffic optimization. Unless non-ALTO compliant traffic will 
be blocked/throttled, but that is hopefully not part of the vision.

György

DePriest, Greg (NBC Universal) wrote:
>>> ALTO requirements already provide for authorized access to the ALTO
>>>       
> service:
>   
>>>    REQ.  ARv00-27: The ALTO client protocol MUST support mechanisms
>>>       
> for
>   
>>>    mutual authentication and authorization of ALTO clients and
>>>       
> servers.
>   
>>> In the particular case of content protection, I can think of
>>>       
> something like this:
>   
>>>                          |
>>>                          |----> Future mechanisms
>>>                          |
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>         
> Of
>   
>>>> Nicholas Weaver
>>>>> I'm not an expert in such matters, have very limited exposure to
>>>>>           
> the
>   
>>>> other P2P optimization (eg, optimizing for low latency for DHTs)
>>>>         
> where
>   
>>>> hashes don't have meaning.  ALTO doesn't want to deal with
>>>>         
> particular
>   
>>>> namespaces from different P2P programs.  Thus defining ID as a UUID
>>>>         
> or
>

---

From: "Y. R. Yang" <[email-masked]>
Date: Mon, 4 May 2009 14:52:51 -0400 (EDT)

Dear Greg,

First let me make it clear that protecting content C1 is a problem that we 
also have interest to solve. 

>From your email, it is clear that your ultimate goal is to protect C1. 
Thank you for making it clear. Also from your email, it appears that at 
this moment you are more targeting C3 (i.e., network proximity/cost 
information, unless your interpretation of ALTO service is a complete 
end-to-end content distribution service). I marked two places with ^^^ to 
indicate this interpretation. Is my interpretation right?

Personally, I feel that protecting C3 is a more reasonable objective to be 
addressed by ALTO, should ALTO decide to pursue it.

Even for C3, it is a challenging issue. Authentication/access control 
protocols (to protect access to C3) are not hard to design. But the 
trust/business issues are much harder to get right. You have asked a very 
good question at the end: "who operates the ALTO service?" I feel that we 
should at least allow each ISP to operate its own ALTO service (providing 
C3). Then which entities should have the authority/trust to tell an 
autonomous ISP that the ISP should give the C3 info of the ISP to some 
ALTO clients but not to others? Without clear understanding of such 
issues, it may unnecessarily complicate the design of the basic ALTO 
service (providing C3) at this moment. What do you think?

Richard

> that's my goal (denying ALTO access, e.g.).  
                  ^^^^^^^^^^^^^^^^^^^
> should not qualify for ALTO service. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---

From: Jon Peterson <[email-masked]>
Date: Mon, 04 May 2009 12:01:23 -0700

The whole question of whether various uses of peer-to-peer networks should
be denied access to the ALTO service is not one that impacts the design of
the ALTO protocol in any meaningful way.

While I won't go so far as to say that these sorts of debates about the
scope of our work are counterproductive, they certainly yield diminishing
returns after a certain point, and I believe we're at that point if we
haven't passed it already. I think it has been amply substantiated that the
ALTO service is poorly positioned to enforce policy, largely due to the fact
that the large installed base of applications will use ALTO only if it
provides an ostensible benefit. Similarly, any ALTO service can elect not to
handle requests from particular sources at its discretion, but I sincerely
doubt we have any authority to influence that decision.

Our job here is to remain focused on the technical design of this
optimization, not on the various policy issues that arise in some use cases
of the larger system. Commingling them will almost certainly render this
work unsuitable for most applications.

Jon Peterson
NeuStar, Inc.