Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs

[Salman Abdul Baset <sa2086 at columbia.edu>]

> - Expose more information about TCP streams. For example, expose whether 
> the stream is congested. Currently some p2p applications use a variety 
> of techniques to attempt to guess whether a user's internet connection 
> is congested (e.g. monitoring ping times), and measures stream 
> throughput which could be viewed as a very rough measure of congestion, 
> but it would be more accurate and efficient if TCP told the application 
> when a stream was congested. Even better would be to get some indication 
> of where the congestion occurred. For example, if the congestion is in 
> the 'last mile', or the other peer's 'last mile', or somewhere in 
> between, different responses would be appropriate. For example, if my 
> internet connection is fine, but the peer's connection is congested, I 
> should slow down transfers from that peer, and pull more from other 
> peers. This is, of course, easier said than done.

It is possible to query the congestion state of a TCP connection in Linux 
using getsockopt() and tcp_info structure. It giveFrom p2pi-bounces at ietf.org  Mon Jun  2 10:01:33 2008
Return-Path: <p2pi-bounces at ietf.org>
X-Original-To: p2pi-archive at ietf.org
Delivered-To: ietfarch-p2pi-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C995F3A69E4;
	Mon,  2 Jun 2008 10:01:32 -0700 (PDT)
X-Original-To: p2pi at core3.amsl.com
Delivered-To: p2pi at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A84DB3A69ED
	for <p2pi at core3.amsl.com>; Mon,  2 Jun 2008 10:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Qr7PiB5eH613 for <p2pi at core3.amsl.com>;
	Mon,  2 Jun 2008 10:01:26 -0700 (PDT)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6])
	by core3.amsl.com (Postfix) with ESMTP id 8C0A828C198
	for <p2pi at ietf.org>; Mon,  2 Jun 2008 09:50:45 -0700 (PDT)
Received: from banana.cc.columbia.edu (banana.cc.columbia.edu [128.59.29.54])
	by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id
	m52Gog63006303; Mon, 2 Jun 2008 12:50:42 -0400 (EDT)
Received: from banana.cc.columbia.edu (localhost [127.0.0.1])
	by banana.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m52GogxG025415; 
	Mon, 2 Jun 2008 12:50:42 -0400 (EDT)
Received: from localhost (sa2086 at localhost)
	by banana.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id
	m52GofYB025407; Mon, 2 Jun 2008 12:50:41 -0400 (EDT)
X-Authentication-Warning: banana.cc.columbia.edu: sa2086 owned process doing
	-bs
Date: Mon, 2 Jun 2008 12:50:41 -0400 (EDT)
From: Salman Abdul Baset <sa2086 at columbia.edu>
To: Laird Popkin <laird at pando.com>
In-Reply-To: <1865369468.307061212422766942.JavaMail.root at dkny.pando.com>
Message-ID: <alpine.SOC.1.00.0806021210320.20490 at banana.cc.columbia.edu>
References: <1865369468.307061212422766942.JavaMail.root at dkny.pando.com>
User-Agent: Alpine 1.00 (SOC 882 2007-12-20)
MIME-Version: 1.0
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6
Cc: ramit at pando.com, p2pi at ietf.org, p4pwg at yahoogroups.com
Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs
X-BeenThere: p2pi at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>,
	<mailto:p2pi-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi at ietf.org>
List-Help: <mailto:p2pi-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>,
	<mailto:p2pi-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces at ietf.org
Errors-To: p2pi-bounces at ietf.org


> - Expose more information about TCP streams. For example, expose whether 
> the stream is congested. Currently some p2p applications use a variety 
> of techniques to attempt to guess whether a user's internet connection 
> is congested (e.g. monitoring ping times), and measures stream 
> throughput which could be viewed as a very rough measure of congestion, 
> but it would be more accurate and efficient if TCP told the application 
> when a stream was congested. Even better would be to get some indication 
> of where the congestion occurred. For example, if the congestion is in 
> the 'last mile', or the other peer's 'last mile', or somewhere in 
> between, different responses would be appropriate. For example, if my 
> internet connection is fine, but the peer's connection is congested, I 
> should slow down transfers from that peer, and pull more from other 
> peers. This is, of course, easier said than done.

It is possible to query the congestion state of a TCP connection in Linux 
using getsockopt() and tcp_info structure. It gives an inds an indication whether 
a connection is in timeout, fast retransmit, fast recovery or congestion 
avoidance. It is also possible to query the TCP transmit and receive 
queue size (in addition to buffer size). I think Windows Vista implements 
a similar mechanism but not sure about it.


> - Expose some measure of 'communications cost' so that p2p apps could 
> select the lowest cost available data sources. (This is what the P4P 
> protocol does, for example). If using this guidance benefits both P2Ps 
> and ISPs, it is a win-win. This is a fairly broad area that might 
> include a number of steps/messages/protocols in order to address service 
> location, mapping IPs to location, and "cost". The P4PWG is researching 
> this area, and while it feels a little early to propose a standard, it's 
> certainly an area (IMO) that could benefit from attention.

Both short-term and long term solutions may be needed here. Mechanisms for 
delivering this cost need to be different than the ways in which cost can 
be specified. Solution spectrum ranges from passing the complete BGP state 
to end nodes to end-host driven computations for communication costs.


> - ISP's could expose usage metrics. For example, if a user has a link 
> that is capable of 1 Mbps, has a monthly transfer capacity of 500 GB, 
> and has used 350 GB so far, then the application can make better 
> choices, and application users could make informed choices. If the ISP 
> could tell applications when the user's internet connection is 
> congested, that would be extremely helpful.

Definitely. Perhaps, need to borrow ideas from the mobile networks/apps 
such as 'view my minutes' option or allow a user to see the usage 
statistics (iPhone).

-s
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi


ication whether 
a connection is in timeout, fast retransmit, fast recovery or congestion 
avoidance. It is also possible to query the TCP transmit and receive 
queue size (in addition to buffer size). I think Windows Vista implements 
a similar mechanism but not sure about it.


> - Expose some measure of 'communications cost' so that p2p apps could 
> select the lowest cost available data sources. (This is what the P4P 
> protocol does, for example). If using this guidance benefits both P2Ps 
> and ISPs, it is a win-win. This is a fairly broad area that might 
> include a number of steps/messages/protocols in order to address service 
> location, mapping IPs to location, and "cost". The P4PWG is researching 
> this area, and while it feels a little early to propose a standard, it's 
> certainly an area (IMO) that could benefit from attention.

Both short-term and long term solutions may be needed here. Mechanisms for 
delivering this cost need to be different than the ways in which cost can 
be specified. Solution spectrum ranges from passing the complete BGP state 
to end nodes to end-host driven computations for communication costs.


> - ISP's could expose usage metrics. For example, if a user has a link 
> that is capable of 1 Mbps, has a monthly transfer capacity of 500 GB, 
> and has used 350 GB so far, then the application can make better 
> choices, and application users could make informed choices. If the ISP 
> could tell applications when the user's internet connection is 
> congested, that would be extremely helpful.

Definitely. Perhaps, need to borrow ideas from the mobile networks/apps 
such as 'view my minutes' option or allow a user to see the usage 
statistics (iPhone).

-s
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi