Re: [p2pi] [tana] [tsv-area] TANA proposed charter

Stanislav Shalunov <shalunov@shlang.com> Tue, 21 October 2008 22:00 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6998628C1B9; Tue, 21 Oct 2008 15:00:59 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B6A28C134 for <p2pi@core3.amsl.com>; Tue, 21 Oct 2008 15:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.959
X-Spam-Level:
X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_53=0.6]
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 AblVWXjhq7oq for <p2pi@core3.amsl.com>; Tue, 21 Oct 2008 15:00:56 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 34DAA3A6BBD for <p2pi@ietf.org>; Tue, 21 Oct 2008 15:00:56 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d18so177241and.122 for <p2pi@ietf.org>; Tue, 21 Oct 2008 15:02:09 -0700 (PDT)
Received: by 10.100.5.15 with SMTP id 15mr10822505ane.50.1224626528953; Tue, 21 Oct 2008 15:02:08 -0700 (PDT)
Received: from ?192.168.1.103? (c-67-188-243-194.hsd1.ca.comcast.net [67.188.243.194]) by mx.google.com with ESMTPS id 30sm11047653yxk.4.2008.10.21.15.02.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 15:02:08 -0700 (PDT)
Message-Id: <466D7202-630F-4F59-B0F7-3C0D32CFB49B@shlang.com>
From: Stanislav Shalunov <shalunov@shlang.com>
To: "Das, Saumitra" <saumitra@qualcomm.com>
In-Reply-To: <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 15:02:04 -0700
References: <mailman.3860.1224623104.4981.p2pi@ietf.org> <4A27D05E36DE7E47B96BCF7DD8F3FD7101D352FD26@NASANEXMB04.na.qualcomm.com>
X-Mailer: Apple Mail (2.929.2)
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>, "tana@ietf.org" <tana@ietf.org>, "p2pi@ietf.org" <p2pi@ietf.org>
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
X-BeenThere: p2pi@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@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

On Oct 21, 2008, at 2:33 PM, Das, Saumitra wrote:

> Overall the problem is scoped well. Just a few clarifications about
> "(2) A document that clarifies the current practices of
> application design and reasons behind them and discusses the
> tradeoffs surrounding the use of many concurrent transport
> connections to one peer and/or to different peers."
>
> This seems a bit too broad. Multiple transport connections to a  
> single peer/server is often used in applications like FDM and other  
> download accelerators. Are we talking about how multiple TANA flows  
> will share a bottleneck in this context or in general about how  
> current TCP flows do this and
> best practices for that such as how many connections to open  
> depending on network characteristics?

The focus is on TCP primarily, but also we'd need to discuss TANA  
connections and, I suppose, TFRC and such.

The genesis of TANA was at the P2PI workshop.  A lot of people there  
were concerned about multiple connections used by P2P apps.  Some  
concerns are meritorious, others require mostly just information --  
there, apparently, exists a belief that P2P apps are designed to open  
multiple TCP connections to the same destination to circumvent TCP  
fairness.  (I even have an inkling of how that one could get started.)

The focus is on long-lived bulk transport connections, and the primary  
push was from correctly observing BitTorrent open a whole ton of TCP  
connections on start.  (Most BitTorrent connections only transmit  
short metadata as it turns out, but still there are several unchoked  
connections with actual data.)  Download managers opening concurrent  
connections would probably qualify.  I expect things like browsers and  
MTAs that open multiple connections to deal with app latencies and  
round-trips would also need to be mentioned for completeness, even  
though they pose no concern for the transport area.

> When we talk about connections to different peers in multi-source  
> downloads what exactly are the tradeoffs we are talking about: is it  
> the impact on ISPs, or that the application could try to choose  
> peers whose AS path or routing path is maximally disjoint. And again  
> is this about how TANA flows
> would work connecting to multiple peers while sharing a common  
> bottleneck at the client or really about multiple TCP flows to  
> different peers and how to choose the peers such that you reduce  
> common bottlenecks in the network.

This being the transport area, we need to examine primarily issues of  
network stability, efficiency, and fairness but, to a smaller extent,  
analyze when an app may or may not be getting the benefit its  
designers thought they would get.

> Maybe the multiple connections work item needs to be elaborated upon  
> to give the correct context.

I'll see what I can do to provide some context for it that is missing  
from the charter for people who didn't attend the workshop.

> Also, I think the name change is useful since there is not inkling  
> that this really is about congestion control. Scavenger Network  
> Congestion Protocols sounds good.

White ball noted.  That makes three.  Incidentally, does anyone  
*dislike* this name?

-- Stas

>
>
> Thanks
> Saumitra
>
> www.saumitra.info
>
> -----Original Message-----
> From: p2pi-bounces@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf  
> Of p2pi-request@ietf.org
> Sent: Tuesday, October 21, 2008 2:05 PM
> To: p2pi@ietf.org
> Subject: p2pi Digest, Vol 7, Issue 27
>
> Send p2pi mailing list submissions to
>        p2pi@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/p2pi
> or, via email, send a message with subject or body 'help' to
>        p2pi-request@ietf.org
>
> You can reach the person managing the list at
>        p2pi-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of p2pi digest..."
>
>
> Today's Topics:
>
>   1. Re: [tsv-area] TANA proposed charter (Ted Faber)
>   2. Re: [tsv-area] TANA proposed charter (Ted Faber)
>   3. Re: [tsv-area] TANA proposed charter (Caitlin Bestler)
>   4. Re: [tana] [tsv-area] TANA proposed charter (Ted Faber)
>   5. Re: ASN utility (Marshall Eubanks)
>   6. Re: WG Review: Application-Layer Traffic Optimization (alto)
>      (Nicholas Weaver)
>   7. Re: ASN utility (David Ward)
>   8. Re: WG Review: Application-Layer Traffic Optimization (alto)
>      (Vijay K. Gurbani)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 21 Oct 2008 09:50:51 -0700
> From: Ted Faber <faber@ISI.EDU>
> Subject: Re: [p2pi] [tsv-area] TANA proposed charter
> To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy@nasa.gov>
> Cc: TSV Area <tsv-area@ietf.org>rg>, tana@ietf.org, p2pi@ietf.org
> Message-ID: <20081021165051.GA64367@zod.isi.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M. (GRC-RCN0) 
> [VZ] wrote:
>> But if nobody else has a problem with the TANA name, I'll keep my  
>> mouth
>> shut so we don't waste time and energy.  There are bigger fish to  
>> fry!
>
> It should change.
>
> I care about congestion control and nothing in the expansion of TANA
> indicated it was about congestion (to me).
>
> --
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 195 bytes
> Desc: not available
> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/d0fa605b/attachment-0001.sig 
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 21 Oct 2008 13:23:27 -0700
> From: Ted Faber <faber@ISI.EDU>
> Subject: Re: [p2pi] [tsv-area] TANA proposed charter
> To: Stanislav Shalunov <shalunov@shlang.com>
> Cc: TSV Area <tsv-area@ietf.org>rg>, tana@ietf.org, p2pi@ietf.org, "Eddy,
>        Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
> Message-ID: <20081021202327.GE64367@zod.isi.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, Oct 21, 2008 at 10:11:37AM -0700, Stanislav Shalunov wrote:
>> On Oct 21, 2008, at 9:50 AM, Ted Faber wrote:
>>> [The TANA name] should change.
>>
>>
>> Would it be sufficient to change the name on the documents and not in
>> the mailing list and the WG name?
>>
>> The WG name will go after we're done.  The documents will remain.
>> This would also allow us to choose the names when the document bodies
>> are already written -- always a plus for relevance...
>
> If you want people who are interested in congestion control to take  
> part
> in your group, "Techniques for Advanced Networking Applications"  
> will do
> nothing to attract their attention.  It is completely generic phrase.
> It could refer to UTF encoding strategies or peer-to-peer load  
> balancing.
>
> It may not be important to you to attract congestion control  
> expertise.
> If it is, I recommend changing the name to something that will get
> busy congestion control people to read past the name.
>
> YMMV.
>
> --
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 195 bytes
> Desc: not available
> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/38f38679/attachment-0001.sig 
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 21 Oct 2008 09:23:01 -0700
> From: Caitlin Bestler <cait@asomi.com>
> Subject: Re: [p2pi] [tsv-area] TANA proposed charter
> To: Murari Sridharan <muraris@microsoft.com>
> Cc: TSV Area <tsv-area@ietf.org>rg>, "tana@ietf.org" <tana@ietf.org>rg>,
>        "p2pi@ietf.org" <p2pi@ietf.org>rg>, "ext Eddy,     Wesley M.
>        \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
> Message-ID: <48FE01E5.5000302@asomi.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Murari Sridharan wrote:
>> Isn't the goal here to achieve lower than best-effort, so  
>> essentially "Low Priority TCP",
>> assuming non-TCP traffic flows E2E we can make it more general and
> call it "Congestion control
>> for low priority flows"
>>
>> Murari
>>
>
> A successful algorithm here would not necessarily "lower than"
> best-effort, because the "low priority' flow could actually achieve
> higher throughput than a conventional TCP flow.
>
> I believe that the key phrase in the proposed charter is very much
> on target -- that the "TANA flows" rapidly yield to conventional TCP.
> It is possible to both rapidly yield *and* to rapidly claim bandwidth
> that conventional TCP algorithms would have left unused.
>
> The extent to which a given algorithm can rapidly claim bandwidth
> without imperiling existing TCP traffic is of course something that
> the WG would have to review. But given the charter objective of
> "saturation" it is important to understand that this is not  
> necessarily
> "low priority" traffic. It is undoubtedly very jitter-tolerant traffic
> that can be quite elastic in its bandwidth utilization for any short
> period of time.
>
> -----
> Caitlin Bestler
> cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 21 Oct 2008 13:31:40 -0700
> From: Ted Faber <faber@ISI.EDU>
> Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
> To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Cc: p2pi@ietf.org, tana@ietf.org, TSV Area <tsv-area@ietf.org>rg>, "Eddy,
>        Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy@nasa.gov>
> Message-ID: <20081021203140.GH64367@zod.isi.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, Oct 21, 2008 at 01:26:46PM -0700, Nicholas Weaver wrote:
>> Why not:
>>
>> Scavenger Network Congestion Protocols?
>
> My ears would prick up for that.
>
> --
> Ted Faber
> http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
> Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 195 bytes
> Desc: not available
> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/9d0b1224/attachment-0001.sig 
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 21 Oct 2008 16:38:30 -0400
> From: Marshall Eubanks <tme@multicasttech.com>
> Subject: Re: [p2pi] ASN utility
> To: Lisa Dusseault <ldusseault@commerce.net>
> Cc: p2pi@ietf.org
> Message-ID: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87@multicasttech.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote:
>
>>
>>
>> When the IESG looked at the proposed ALTO charter last week, Dave
>> had some comments about ASNs which I'd like to follow up on by
>> dragging Dave into the conversation.
>>
>> What I understand the ASN related suggestions so far to be, is to
>> have the ALTO server return a list of ASN numbers to prefer or
>> avoid.  This sort of information could only be provided by an ISP-
>> operated ALTO server.
>
> Are you sure about that ?
>
> A peer can (for example) query route views, or I (or a host of others)
> can send it BGP / address block tables. It would not be hard to
> collate address information with ASN and ASN paths and draw
> conclusions. I don't see why an ISP is necessarily involved.
>
> Regards
> Marshall
>
>
>
>> A peer, armed with this information, can do whatever they do today
>> to figure
>> out which IP address falls in which ASN.  The P4P and Yale folks
>> claim that returning a preference of ASNs helped their application
>> tremendously.
>>
>> Dave, was your concern about discovering ASN being unnecessary, or
>> about ranking of ASNs being unhelpful?  Can you restate?
>>
>> Thanks,
>> Lisa
>> _______________________________________________
>> p2pi mailing list
>> p2pi@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 21 Oct 2008 13:43:30 -0700
> From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
>        (alto)
> To: Karl Auerbach <karl@cavebear.com>
> Cc: "p2pi@ietf.org" <p2pi@ietf.org>rg>,    Nicholas Weaver
>        <nweaver@ICSI.Berkeley.EDU>DU>,    IESG IESG <iesg@ietf.org>rg>,
>        "ietf@ietf.org" <ietf@ietf.org>
> Message-ID: <EE0DFEE3-0646-45F7-B194-199B83B2E9D4@icsi.berkeley.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Hey, stupid thought...
>
> Could you do proximity based on "who's your DNS resolver"?  Do a few
> name lookups: one to register YOU as using YOUR DNS resolver to the
> remote coordinator, and one to get "who are other peers using the same
> resolver"?
>
> An ugly, UGLY hack, but it might be interesting to think about.
>
> Has anyone done this already?
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 21 Oct 2008 15:50:40 -0500
> From: David Ward <dward@cisco.com>
> Subject: Re: [p2pi] ASN utility
> To: Marshall Eubanks <tme@multicasttech.com>
> Cc: p2pi@ietf.org, Lisa Dusseault <ldusseault@commerce.net>
> Message-ID: <10062CD4-88B8-47EC-8809-D02486A3D05D@cisco.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Marshall -
>
> I mentioned that this is one deployment model and is as it works
> today but, the charter is unclear if they want to support any other
> model. I do think it is considerably harder to deduce a current
> AS_path from simple prefix -> ASN information.
>
> -DWard
>
> On Oct 21, 2008, at 3:38 PM, Marshall Eubanks wrote:
>
>>
>> On Sep 29, 2008, at 1:54 PM, Lisa Dusseault wrote:
>>
>>>
>>>
>>> When the IESG looked at the proposed ALTO charter last week, Dave
>>> had some comments about ASNs which I'd like to follow up on by
>>> dragging Dave into the conversation.
>>>
>>> What I understand the ASN related suggestions so far to be, is to
>>> have the ALTO server return a list of ASN numbers to prefer or
>>> avoid.  This sort of information could only be provided by an ISP-
>>> operated ALTO server.
>>
>> Are you sure about that ?
>>
>> A peer can (for example) query route views, or I (or a host of
>> others) can send it BGP / address block tables. It would not be
>> hard to collate address information with ASN and ASN paths and draw
>> conclusions. I don't see why an ISP is necessarily involved.
>>
>> Regards
>> Marshall
>>
>>
>>
>>> A peer, armed with this information, can do whatever they do today
>>> to figure
>>> out which IP address falls in which ASN.  The P4P and Yale folks
>>> claim that returning a preference of ASNs helped their application
>>> tremendously.
>>>
>>> Dave, was your concern about discovering ASN being unnecessary, or
>>> about ranking of ASNs being unhelpful?  Can you restate?
>>>
>>> Thanks,
>>> Lisa
>>> _______________________________________________
>>> p2pi mailing list
>>> p2pi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2pi
>>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 21 Oct 2008 16:05:40 -0500
> From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
>        (alto)
> To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Cc: "p2pi@ietf.org" <p2pi@ietf.org>
> Message-ID: <48FE4424.2000309@alcatel-lucent.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Nicholas Weaver wrote:
>> Hey, stupid thought...
>>
>> Could you do proximity based on "who's your DNS resolver"?  Do a few
>> name lookups: one to register YOU as using YOUR DNS resolver to the
>> remote coordinator, and one to get "who are other peers using the  
>> same
>> resolver"?
>>
>> An ugly, UGLY hack, but it might be interesting to think about.
>>
>> Has anyone done this already?
>
> Doesn't Ono [1] do that?  Or am I missing something?  CDNs also
> use DNS redirects to redirect clients to nearest servers.
>
> [1] David R. Choffnes and Fabi?n E. Bustamante. Taming the Torrent:
>     A practical approach to reducing cross-ISP traffic in P2P
>     systems, Proc. of ACM SIGCOMM 2008, August 2008.
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
>
>
> ------------------------------
>
> _______________________________________________
> p2pi mailing list
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
>
>
> End of p2pi Digest, Vol 7, Issue 27
> ***********************************
> _______________________________________________
> tana mailing list
> tana@ietf.org
> https://www.ietf.org/mailman/listinfo/tana

--
Stanislav Shalunov



_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi