Re: [p2pi] [tana] [tsv-area] TANA proposed charter
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 at ietf.org [mailto:p2pi-bounces at ietf.org] On Behalf Of p2pi-request at ietf.org 
Sent: Tuesday, October 21, 2008 2:05 PM
To: p2pi at ietf.org
Subject: p2pi Digest, Vol 7, Issue 27

Send p2pi mailing list submissions to
       p2pi at 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 at ietf.org

You can reach the person managing the list at
       p2pi-owner at 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 at ISI.EDU>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <Wesley.M.Eddy at nasa.gov>
Cc: TSV Area <tsv-area at ietf.org>, tana at ietf.org, p2pi at ietf.org
Message-ID: <20081021165051.GA64367 at 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 at ISI.EDU>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: Stanislav Shalunov <shalunov at shlang.com>
Cc: TSV Area <tsv-area at ietf.org>, tana at ietf.org, p2pi at ietf.org, "Eddy,
       Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy at nasa.gov>
Message-ID: <20081021202327.GE64367 at 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 at asomi.com>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: Murari Sridharan <muraris at microsoft.com>
Cc: TSV Area <tsv-area at ietf.org>, "tana at ietf.org" <tana at ietf.org>,
       "p2pi at ietf.org" <p2pi at ietf.org>, "ext Eddy,     Wesley M.
       \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy at nasa.gov>
Message-ID: <48FE01E5.5000302 at 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 at asomi.com - http://www.asomi.com/CaitlinBestlerResume.pdf


------------------------------

Message: 4
Date: Tue, 21 Oct 2008 13:31:40 -0700
From: Ted Faber <faber at ISI.EDU>
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
To: Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
Cc: p2pi at ietf.org, tana at ietf.org, TSV Area <tsv-area at ietf.org>, "Eddy,
       Wesley M. \(GRC-RCN0\)\[VZ\]" <Wesley.M.Eddy at nasa.gov>
Message-ID: <20081021203140.GH64367 at 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 at multicasttech.com>
Subject: Re: [p2pi] ASN utility
To: Lisa Dusseault <ldusseault at commerce.net>
Cc: p2pi at ietf.org
Message-ID: <62F04BA8-07BD-4DA4-BB13-09E3498ACA87 at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi




------------------------------

Message: 6
Date: Tue, 21 Oct 2008 13:43:30 -0700
From: Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
       (alto)
To: Karl Auerbach <karl at cavebear.com>
Cc: "p2pi at ietf.org" <p2pi at ietf.org>,    Nicholas Weaver
       <nweaver at ICSI.Berkeley.EDU>,    IESG IESG <iesg at ietf.org>,
       "ietf at ietf.org" <ietf at ietf.org>
Message-ID: <EE0DFEE3-0646-45F7-B194-199B83B2E9D4 at 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 at cisco.com>
Subject: Re: [p2pi] ASN utility
To: Marshall Eubanks <tme at multicasttech.com>
Cc: p2pi at ietf.org, Lisa Dusseault <ldusseault at commerce.net>
Message-ID: <10062CD4-88B8-47EC-8809-D02486A3D05D at 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 at 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 at alcatel-lucent.com>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
       (alto)
To: Nicholas Weaver <nweaver at ICSI.Berkeley.EDU>
Cc: "p2pi at ietf.org" <p2pi at ietf.org>
Message-ID: <48FE4424.2000309 at 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 at {alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs


------------------------------

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


End of p2pi Digest, Vol 7, Issue 27
***********************************
_______________________________________________
tana mailing list
tana at ietf.org
https://www.ietf.org/mailman/listinfo/tana


--
Stanislav Shalunov



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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.