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

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 21 Oct 2008 14:33:02 -0700

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?

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.

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

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.

Thanks
Saumitra

www.saumitra.info

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 21, 2008 2:05 PM
To: [email-masked]
Subject: p2pi Digest, Vol 7, Issue 27

Send p2pi mailing list submissions to
        [email-masked]

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
        [email-masked]

You can reach the person managing the list at
        [email-masked]

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 <[email-masked]>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Cc: TSV Area <[email-masked]>, [email-masked], [email-masked]
Message-ID: <[email-masked]>
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 <[email-masked]>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: Stanislav Shalunov <[email-masked]>
Cc: TSV Area <[email-masked]>, [email-masked], [email-masked], "Eddy,
        Wesley M. \(GRC-RCN0\)\[VZ\]" <[email-masked]>
Message-ID: <[email-masked]>
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 <[email-masked]>
Subject: Re: [p2pi] [tsv-area] TANA proposed charter
To: Murari Sridharan <[email-masked]>
Cc: TSV Area <[email-masked]>, "[email-masked]" <[email-masked]>,
        "[email-masked]" <[email-masked]>, "ext Eddy,     Wesley M.
        \(GRC-RCN0\)\[VZ\]" <[email-masked]>
Message-ID: <[email-masked]>
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
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.pdf

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

Message: 4
Date: Tue, 21 Oct 2008 13:31:40 -0700
From: Ted Faber <[email-masked]>
Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked], [email-masked], TSV Area <[email-masked]>, "Eddy,
        Wesley M. \(GRC-RCN0\)\[VZ\]" <[email-masked]>
Message-ID: <[email-masked]>
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 <[email-masked]>
Subject: Re: [p2pi] ASN utility
To: Lisa Dusseault <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2pi

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

Message: 6
Date: Tue, 21 Oct 2008 13:43:30 -0700
From: Nicholas Weaver <[email-masked]>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
        (alto)
To: Karl Auerbach <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,    Nicholas Weaver
        <[email-masked]>,    IESG IESG <[email-masked]>,
        "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
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 <[email-masked]>
Subject: Re: [p2pi] ASN utility
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>
Message-ID: <[email-masked]>
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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2pi
>

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

Message: 8
Date: Tue, 21 Oct 2008 16:05:40 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization
        (alto)
To: Nicholas Weaver <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

End of p2pi Digest, Vol 7, Issue 27
***********************************
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 15:02:04 -0700

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

> 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

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.

> 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

> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/d0fa605b/attachment-0001.sig 
> >
>
> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/38f38679/attachment-0001.sig 
> >
>
> Url : <http://www.ietf.org/pipermail/p2pi/attachments/20081021/9d0b1224/attachment-0001.sig 
> >
>

--
Stanislav Shalunov

---

From: "Robb Topolski" <[email-masked]>
Date: Sun, 26 Oct 2008 21:52:49 -0700

For reasons I don't quite understand, my view of this conversation is very
fragmented.

On Tue, Oct 21, 2008 at 3:02 PM, Stanislav Shalunov <[email-masked]>wrote:

> 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.)
>

People also said that P2P applications filled up all available bandwidth,
with no explanation provided as to how these applications exceed the limits
programmatically imposed by the ISP.

Before anyone redefines fairness, we need data on the current situation.  We
need to ensure that redefining fairness isn't simply suppressing a market
choice.  One ISP is reportedly prioritizing HTTP above most other traffic.
If, 15 years ago, someone prioritized Gopher over all other traffic, then
probably never would have succeeded it.

Please let's not write this problem statement without data confirming the
problem and the size of the fairness bias (which probably does exist on
paper, but we have no data as to the extent given these applications at
ISP-subscriber speeds and P2P latencies).

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?
>
>
I worry about the idea of moving congestion management and packet handling
instructions up a layer in the network stack.   Worry is not fatal, but it
fogs up an area of clarity.  I also worry that the last two attempts to help
transit providers understand their customer's packets handling needs haven't
really been seriously trialled by ISPs as far as I know.

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana