RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

["Narayanan, Vidya" <vidyan at qualcomm.com>]

Hi Martin,
Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't.  At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers.  Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable.  We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests.

Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture.

Thanks,
Vidya

> -----Original Message-----
> From: Martin Stiemerling [mailto:Stiemerling at nw.neclab.eu]
> Sent: Monday, October 13, 2008 8:03 AM
> To: Narayanan, Vidya; Vijay K. Gurbani
> Cc: p2pi at ietf.org; IESG IESG; ietf at ietf.org
> Subject: RE: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> Hi Vidja, all,
>
> I believe that the charter is narrow and broad enough to
> cover the topic of ALTO, i.e., the charter is not limiting
> the solution space.
>
> However, when reading your comments, it sounds that you have
> a very specific solution in mind which is probably not
> covered by the current charter.
>
> [...]
>
> > >
> > > > Overall, I think we should work with the notion of an ALTO
> > "service"
> > > >  rather than specifically an ALTO "server".
> > >
> > > Great.  I believe that is exactly what the charter does;  the
> > > charter talks in terms of an "ALTO service" at many places
> > > (pedantically speaking, the term "ALTO service" occurs
> eight times
> > > and the term "ALTO server" occurs six.)  The ALTO "server"
> > > mentioned in the charter refers to the *host* the client finally
> > > queries (calling it a "peer" is ambiguous; if you have a specific
> > > term to use here instead of "server", please do let us know.)
> > >
> >
> > When we consider ALTO as a distributed service, there may not
> > necessarily be "a" host that specifically resolves the ALTO queries.
> > For instance, consider the case where ALTO is a service
> offered in an
> > overlay.  There may be peers publishing information about
> themselves
> > on the overlay and other peers looking up such information.
>  These are
> > not necessarily client-server style communications.  In
> fact, all that
> > is important in this context is that the overlay acts as a
> rendezvous
> > for sharing such information.  Now, of course, that is one
> possible model.
>
> You probably have a publish/subscribe system in mind for p2p overlays.
> I assume this is not in scope of ALTO.
>
> > But, in order to allow for that and other models, I do want the
> > charter to keep the focus on the service and not on a server.
>
> Is the IETF anyhow standardizing services? I don't see this.
>
> [...]
>
>
> > >
> > > We have had discussions on the mailing list about this already.
> > > Some people felt that providing uplink bandwidth would
> not be a good
> > > idea for various reasons running from privacy concerns to peers
> > > skewing traffic in favor of a high uplink bandwidth.
> > > Others felt that even if a peers uplink bandwidth was not
> provided,
> > > it could calculated nonetheless by other peers.
> > > That is, there are degrees of disagreement here and consequently,
> > > including a contentious point in the charter would be counter-
> > > productive.
> > >
> >
> > I'm afraid that would be a mistake.  It actually doesn't
> matter if we
>
> I'm afraid that carrying up/downlink capacity of the peer's
> local link is a complete waste of resource, as this is not
> indicating something. For instance, a peer may have a
> relatively huge uplink but on a shared medium, i.e., a medium
> which might be shared by hundreds of other hosts/traffic.
> So what does this information express?
>
> > don't agree today on the exact types of information that
> can be shared.
> > It is important that we have a protocol that allows peers
> to publish
> > ALTO related information.  Having this protocol be extensible would
> > allow for any type of information to be carried in it.  So,
> I strongly
>
> The question is, whether the roots of ALTO are actually
> intended to carry any type of information? The main idea is
> to carry information to optimize traffic, e.g., decreasing
> cross ISP traffic.
>
> > believe we don't need a recharter to consider any
> information types -
> > in fact, I'd be okay if this effort only took on the
> protocol and if
> > all information types were to be registered through other
> means.  That
> > said, I'm not against taking on some subset of those types
> - I don't
> > believe that should be the core focus of this work though.
> >
> > > > - The ability to register information types with IANA
> and extend
> > > > these.
> > >
> > > Having a IANA registry for the information type carried in the
> > > protocol is certainly a possibility the charter does not
> rule out,
> > > no?
> > >
> >
> > Well, it is a bit hard to say what the charter does not rule out -
> > typically we try and do what the charter says we should do.
>  However,
> > before we get to the registry, we need to agree on the protocol
> > components.  In my view, there are two such components -
> the publish
> > protocol mentioned above and the request/response protocol
> (actually,
> > more generically, a lookup protocol) mentioned below.
>
> It is good to see your ideas but doesn't this go beyond a
> charter discussion, as your are discussing a solution?
>
> This comes back to my initial comment about discussing a
> specific solution, and we haven't yet reached the times to
> discuss a solution - at least not here.
>
>   Martin
>
>
> stiemerling at nw.neclab.eu
>
> NEC Laboratories Europe - Network Research Division NEC
> Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
>
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


soft SMTP Server
	(TLS) id 8.1.291.1; Tue, 14 Oct 2008 17:09:50 -0700
Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by
	nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP
	Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 17:09:50 -0700
Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by
	nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi;
	Tue, 14 Oct 2008 17:09:49 -0700
From: "Narayanan, Vidya" <vidyan at qualcomm.com>
To: Martin Stiemerling <Stiemerling at nw.neclab.eu>, "Vijay K. Gurbani"
	<vkg at alcatel-lucent.com>
Date: Tue, 14 Oct 2008 17:09:49 -0700
Subject: RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Topic: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Thread-Index: AckrB8UxxycZhW5DQNmtzaNDmm9pNgACj0qwAIwwruAAOrX48A==
Message-ID: <BE82361A0E26874DBC2ED1BA244866B9276376FA at NALASEXMB08.na.qualcomm.com>
References: <20081006203532.B1D673A68AF at core3.amsl.com><BE82361A0E26874DBC2ED1BA244866B9276373BA at NALASEXMB08.na.qualcomm.com><48EFA1B7.7010508 at alcatel-lucent.com>
	<BE82361A0E26874DBC2ED1BA244866B92763750C at NALASEXMB08.na.qualcomm.com>
	<547F018265F92642B577B986577D671C3DF92C at VENUS.office>
In-Reply-To: <547F018265F92642B577B986577D671C3DF92C at VENUS.office>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "p2pi at ietf.org" <p2pi at ietf.org>, IESG IESG <iesg at ietf.org>,
	"ietf at ietf.org" <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Hi Martin,
Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't.  At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers.  Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable.  We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests.

Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture.

Thanks,
Vidya

> -----Original Message-----
> From: Martin Stiemerling [mailto:Stiemerling at nw.neclab.eu]
> Sent: Monday, October 13, 2008 8:03 AM
> To: Narayanan, Vidya; Vijay K. Gurbani
> Cc: p2pi at ietf.org; IESG IESG; ietf at ietf.org
> Subject: RE: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> Hi Vidja, all,
>
> I believe that the charter is narrow and broad enough to
> cover the topic of ALTO, i.e., the charter is not limiting
> the solution space.
>
> However, when reading your comments, it sounds that you have
> a very specific solution in mind which is probably not
> covered by the current charter.
>
> [...]
>
> > >
> > > > Overall, I think we should work with the notion of an ALTO
> > "service"
> > > >  rather than specifically an ALTO "server".
> > >
> > > Great.  I believe that is exactly what the charter does;  the
> > > charter talks in terms of an "ALTO service" at many places
> > > (pedantically speaking, the term "ALTO service" occurs
> eight times
> > > and the term "ALTO server" occurs six.)  The ALTO "server"
> > > mentioned in the charter refers to the *host* the client finally
> > > queries (calling it a "peer" is ambiguous; if you have a specific
> > > term to use here instead of "server", please do let us know.)
> > >
> >
> > When we consider ALTO as a distributed service, there may not
> > necessarily be "a" host that specifically resolves the ALTO queries.
> > For instance, consider the case where ALTO is a service
> offered in an
> > overlay.  There may be peers publishing information about
> themselves
> > on the overlay and other peers looking up such information.
>  These are
> > not necessarily client-server style communications.  In
> fact, all that
> > is important in this context is that the overlay acts as a
> rendezvous
> > for sharing such information.  Now, of course, that is one
> possible model.
>
> You probably have a publish/subscribe system in mind for p2p overlays.
> I assume this is not in scope of ALTO.
>
> > But, in order to allow for that and other models, I do want the
> > charter to keep the focus on the service and not on a server.
>
> Is the IETF anyhow standardizing services? I don't see this.
>
> [...]
>
>
> > >
> > > We have had discussions on the mailing list about this already.
> > > Some people felt that providing uplink bandwidth would
> not be a good
> > > idea for various reasons running from privacy concerns to peers
> > > skewing traffic in favor of a high uplink bandwidth.
> > > Others felt that even if a peers uplink bandwidth was not
> provided,
> > > it could calculated nonetheless by other peers.
> > > That is, there are degrees of disagreement here and consequently,
> > > including a contentious point in the charter would be counter-
> > > productive.
> > >
> >
> > I'm afraid that would be a mistake.  It actually doesn't
> matter if we
>
> I'm afraid that carrying up/downlink capacity of the peer's
> local link is a complete waste of resource, as this is not
> indicating something. For instance, a peer may have a
> relatively huge uplink but on a shared medium, i.e., a medium
> which might be shared by hundreds of other hosts/traffic.
> So what does this information express?
>
> > don't agree today on the exact types of information that
> can be shared.
> > It is important that we have a protocol that allows peers
> to publish
> > ALTO related information.  Having this protocol be extensible would
> > allow for any type of information to be carried in it.  So,
> I strongly
>
> The question is, whether the roots of ALTO are actually
> intended to carry any type of information? The main idea is
> to carry information to optimize traffic, e.g., decreasing
> cross ISP traffic.
>
> > believe we don't need a recharter to consider any
> information types -
> > in fact, I'd be okay if this effort only took on the
> protocol and if
> > all information types were to be registered through other
> means.  That
> > said, I'm not against taking on some subset of those types
> - I don't
> > believe that should be the core focus of this work though.
> >
> > > > - The ability to register information types with IANA
> and extend
> > > > these.
> > >
> > > Having a IANA registry for the information type carried in the
> > > protocol is certainly a possibility the charter does not
> rule out,
> > > no?
> > >
> >
> > Well, it is a bit hard to say what the charter does not rule out -
> > typically we try and do what the charter says we should do.
>  However,
> > before we get to the registry, we need to agree on the protocol
> > components.  In my view, there are two such components -
> the publish
> > protocol mentioned above and the request/response protocol
> (actually,
> > more generically, a lookup protocol) mentioned below.
>
> It is good to see your ideas but doesn't this go beyond a
> charter discussion, as your are discussing a solution?
>
> This comes back to my initial comment about discussing a
> specific solution, and we haven't yet reached the times to
> discuss a solution - at least not here.
>
>   Martin
>
>
> stiemerling at nw.neclab.eu
>
> NEC Laboratories Europe - Network Research Division NEC
> Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
>
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf