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

["Das, Saumitra" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Tuesday, October 21, 2008 2:05 PM
To: [e-mail]
Subject: p2pi Digest, Vol 7, Issue 27

Send p2pi mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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


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

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



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

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



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

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


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