Subject: Re: [ledbat] Commitment to contribute by P2P-next project

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 7 Aug 2009 14:39:38 -0700

Johan,

Sharing information explicitly among multiple connections from the
same client is a promising area.  (If I understood correctly the
direction of what you're doing.)

It'd be great to know more about the technique in question, and its
applicability to various forms of congestion control.  Is it a
specific congestion control mechanism or a way to modify other
congestion control mechanisms to take advantage of the knowledge that
the upload is 1:n?

Thanks,

-- Stas

On Mon, Jul 27, 2009 at 3:38 PM, Johan Pouwelse<[email-masked]> wrote:
> Dear ledbat group,
>
> Hereby the P2P-Next research group commits itself to contributing to Ledbat
> a 'next-generation congestion control algorithm'.
>
> We have developed new algorithms and initial running Open Source code which
> we are expanding. Before the end of this year we are planning to conduct an
> open Internet trial with over 50.000 participants.
> P2P-Next is a European Union sponsored project with a budget of 19 million
> Euro. We are commited to use part of these resources to deploy and
> standardize a novel congestion control algorithm.
> We have reviewed in detail the current proposals on the Stockholm agenda.
> Our key contribution due before end of 2009 is an algorithm which is
> designed to move beyond the 1-to-1 context of current state-of-the-art. We
> improve efficiency by utilising the fact that large majority of background
> upload traffic takes place in a 1 uploader to N receivers context. Our
> initial measurements indicate that local and remote congestion can be
> identified with superior accuracy if this context is exploited.
>
> From the strategic side we plan to be completely open about sharing of our
> Open Source code, algorithms and (anonymised) datasets.
>
> By contacting you prior to this meeting we hope that you can take our work
> into account when relevant.
> The technical detail of our work will be given within a month from now.
>
> Greetings,
> Dr. Johan pouwelse, scientific director of P2P-next.
>
> On Jul 27, 2009 5:48 AM, "Bernard Aboba" <[email-masked]> wrote:
>
> LEDBAT WG Meeting
> IETF 75
> Stockholm, Sweden
>
> Chairs:  S. Shalunov
>          M. Sridharan
>          B. Aboba (acting)
>
> Wednesday, July 29, 2009
> 13:00 - 15:00
> Congresshall B
>
> Preliminaries (10 minutes)
>
> Note well
> Blue Sheets
> Minute Takers
> Jabber Scribe
> Agenda bashing
> Document Status
>
> Documents Under Consideration for Adoption as a WG Work Item (80 minutes)
>
> 13:10 - 13:40  Low Extra Delay Background  Transport (LEDBAT), S. Shalunov
> (30 minutes)
> http://tools.ietf.org/id/draft-shalunov-ledbat-congestion
>
> 13:40 – 14:10 LEDBAT Practices and Recommendations, R. Penno (30 minutes)
> http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations
>
> 14:10 – 14:30 A Survey of Lower-than-Best Effort Transport Protocols, M.
> Welzl (20 minutes)
> http://tools.ietf.org/html/draft-welzl-ledbat-survey
>
> Next Steps and Wrapup (30 minutes)
>
> 14:30 – 15:00 Chairs & Area Directors (30 minutes)
>
>
>
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat
>
>
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat
>
>

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Joe Touch <[email-masked]>
Date: Sat, 08 Aug 2009 20:40:51 -0700

> direction of what you're doing.)

Sharing can be within a single client or among clients with similar
properties (e.g., within a LAN). Both techniques are described in
RFC2140 ;-)

> congestion control mechanisms to take advantage of the knowledge that

2140 noted that in some cases you can help congestion control converge
more quickly (or avoid competition between flows from the same machine)
by doing a "divide by N", which can be adjusted to "divide by N+1" when
you add a connection or "divide by N-1" when a connection ends.

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 9 Aug 2009 14:30:11 -0700

> properties (e.g., within a LAN). Both techniques are described in

Joe,

I had two questions:

1. Do you expect this could be applicable to situations when connections
share one endpoint but never another?

2. Let's call an information-sharing scheme split-resistant if the mean of
the produced behavior of every flow remains the same when the scheme is
active.  Are all modifications in RFC 2140 intended to be split-resistant?
 (I see that a lot are, but maybe I'm missing something.)

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Sun, 09 Aug 2009 17:52:52 -0700

Stanislav Shalunov wrote:
> On Sat, Aug 8, 2009 at 8:40 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Sure. If the other end shares a prefix, it's likely they share a
congestion point, so they probably can be shared. That's the key. If you
suspect there's shared path properties, then coordinated connection
management is appropriate.

> 2. Let's call an information-sharing scheme split-resistant if the mean
> of the produced behavior of every flow remains the same when the scheme
> is active.  Are all modifications in RFC 2140 intended to be
> split-resistant?  (I see that a lot are, but maybe I'm missing something.)

2140 explains that sharing is possible and consistent with existing
congestion control (i.e., it makes things converge faster). It focuses
on coarse properties - CWND, MSS, RTT, and lets each connection operate
independently otherwise; with those mods, the changes in behavior focus
on making the connections converge - not making N connections behave
exactly like 1. 2140 doesn't specify the sharing alg in detail.

Joe

---

From: Lachlan Andrew <[email-masked]>
Date: Mon, 10 Aug 2009 11:06:55 +1000

2009/8/10 Joe Touch <[email-masked]>:
> congestion point,

How much of a prefix should they share?  If they share the first byte,
that tells us almost nothing.  Even if they share the same AS, the
congestion point is likely to be towards the edge of the AS, which is
highly likely not to be shared, isn't it?

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

---

From: Lars Eggert <[email-masked]>
Date: Mon, 10 Aug 2009 11:00:24 +0300

> highly likely not to be shared, isn't it?

Section 2 of the Ensemble-TCP paper (link in a recent email) discusses  
this a bit.

Lars

---

From: Murari Sridharan <[email-masked]>
Date: Mon, 10 Aug 2009 18:01:57 +0000

I guess the key would be to detect if you are sharing a path instead of purely going by prefix.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lachlan Andrew
Sent: Sunday, August 09, 2009 6:07 PM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [ledbat] Commitment to contribute by P2P-next project

Cheers,
Lachlan

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2009 11:05:45 -0700

> I guess the key would be to detect if you are sharing a path instead of purely going by prefix.

Ultimately, yes. If you know there are shared path characteristics, then
you know you can coordinate the state. Prefixes are just something to
use as a correlator.

Joe