Subject: [tsv-area] discussing P2PI-related standardization in Dublin

From: Lars Eggert <[email-masked]>
Date: Fri, 6 Jun 2008 15:58:11 +0200

Hi,

the recent workshop on P2P infrastructure (P2PI) has
resulted in several suggestions for future IETF work. Two of
the suggested work items are related to core TSV topics, and
a third has at least strong ties to TSV (but also to other
areas).

We'd be interested to hear from the community if we should
schedule a BOF in Dublin to discuss whether the IETF should
take on some or all of these, and if so, whether TSV would
be the right place for this work.

I'll be CC'ing this email to several lists. Please direct
your replies to the TSV area list ([email-masked]), so
that the discussion happens in one place.

The working title for the BOF is "Techniques for Advanced
Networking Applications" or TANA. The high-level idea is
that the IETF would develop guidelines, recommendations and
mechanisms for advanced applications that make intensive use
of Internet communication in a way that goes beyond the
capabilities offered by the IETF's current standard
end-to-end transport protocols. Such network-centric
applications include those that transmit delay-sensitive
traffic and those that transmit delay-insensitive traffic,
both using either peer-to-peer approaches or more
traditionally structured communication patterns. The work
would focus on broadly applicable techniques that address
the needs of large subsets of these class of network-centric
applications in a fashion that is independent of any
particular application.

The following three work items were identified as potential
new work for the IETF at the P2PI workshop. The first two
would be pretty clearly in scope for the TSV area, whereas
the third has some significant inter-area relations:

(1) A congestion control algorithm for
     less-than-best-effort "background" transmissions, i.e.,
     an algorithm that attempts to scavenge otherwise idle
     bandwidth for its transmissions in a way that minimizes
     interference with regular best-effort traffic. Among the
     desired features of such an algorithm are the ability to
     maintain short standing queues, the capability to quickly
     yield to regular best-effort traffic that uses standard
     congestion control, the ability to utilize explicit
     congestion notification (ECN), active queue management
     (AQM), and/or end-to-end differentiated services
     (DiffServ) where available, as well as effective
     operation in situations where some or all of these
     mechanisms are not available. In addition to specifying a
     congestion control algorithm, the work may also include
     specifications of how the algorithm is used in specific
     UDP-based protocols. (Application of the algorithm to
     other transport protocols is expected to occur in the
     working groups that maintain those protocols.) This work
     item has relations to IETF WGs that deal with congestion
     control, such as TCPM, DCCP and TSVWG, as well as the
     IRTF's congestion control research group (ICCRG).

(2) A guidelines document that discusses the tradeoffs
     surrounding the use of many concurrent transport
     connections to one peer and/or to different peers.
     Standard Internet congestion control results in a state
     where different transport connections end up sharing
     bottleneck capacity, and when an application uses several
     transport connections to transfer through a bottleneck,
     it tends to end up with a larger fraction of the
     bottleneck's loaded resource than if it would be using
     fewer connections. Note that although capacity is the
     most commonly considered bottleneck resource, middlebox
     state table entries are a second important resource for
     end system communication. Other resource types may exist,
     and the guidelines are expected to comprehensively
     discuss them.

(3) A mechanism that lets an application that can
     transfer data from or to several potential peers (i.e.,
     servers, caches, end systems) select a subset of peers
     for efficient transmission in a way that is aligned with
     the dynamic interconnection structure of the network
     operators that provide connectivity to those peers.
     Application designers, network equipment vendors and
     network operators will need to collaborate on this work
     item to define what kinds of dynamic interconnection
     information is useful to applications, how to obtain it,
     and how to provide it to applications, resulting in a
     generic mechanism that is broadly applicable to many
     current and future applications. This work item has
     obvious interactions with the IETF's Application, Routing
     and Operations areas. In order to make this effort more
     manageable, it may make sense to work out the
     requirements for such a solution first, before discussing
     individual proposals or breaking up the work into pieces
     for specification in different areas or WGs.

Please send your thoughts on these three topics.

These three work items aren't necessarily the only ones that
the IETF could think about taking on; they merely appeared
to be the most concrete ones coming out of the P2PI
workshop. We could think about discussing additional work
items in Dublin - please write up a short description
(similar to the ones above), so we can discuss them.

Lars

---

From: Michael Welzl <[email-masked]>
Date: Fri, 06 Jun 2008 16:34:55 +0200

Hi,

>      IRTF's congestion control research group (ICCRG).

Several such mechanisms exist - cf. the "Below-Best-Effort TCP
and Related Work" heading at http://www.icir.org/floyd/tcp_small.html
and could be implemented right away on top of UDP - but is anyone
doing this? I think that nobody ever uses such mechanisms.

To look at the complementary side of things, is anyone actually
deploying RFC 3662?

I think that it's a great idea, no matter which side we
deploy it on, but how do we get people to use these things?

Cheers,
Michael

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Jun 2008 17:41:18 +0300

Michael,

> deploy it on, but how do we get people to use these things?
Implement it into protocols that people use in the real world, such as 
Bittorrent.

Ciao
Hannes

PS: If I understood it correctly then they actually have something 
implemented already.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 6 Jun 2008 16:40:36 +0200

Hi,

related to the work item below, I've just heard that some folks had  
already been discussing the submission of a more targeted BOF  
proposal. Depending on the details of that proposal (which I haven't  
seen yet), work item (3) might be subsumed by it.

Lars

---

From: "Mascolo Saverio" <[email-masked]>
Date: Fri, 6 Jun 2008 16:39:32 +0200

hi lars,

can you explian more the point (3) below, expecially what do u mean by
"is aligned with   the dynamic interconnection structure of the network
    operators that provide connectivity to those peers"?

thanks
saverio

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://www-dee.poliba.it/dee-web/Personale/mascolo.html

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 06 Jun 2008 11:36:17 -0500

>      an algorithm that attempts to scavenge otherwise idle
[...]

I ran across the following references today that I thought
may be pertinent to congestion control in DHT algorithms.
I do not think they operate on the scavenger principle,
nor do I remember them as references in the P2Pi workshop
set of papers.

Fabius Klemm, Jean-Yves Le Boudec, Karl Aberer: Congestion
Control for Distributed Hash Tables. The 5th IEEE International
Symposium on Network Computing and Applications (IEEE NCA06),
Cambridge, MA, USA, July 24 - 26, 2006 (available online at
http://lsirpeople.epfl.ch/klemm/Congestion%20Control%20for%20Distributed%20Hash%20Tables.pdf)

Fabius Klemm, Jean-Yves Le Boudec, Dejan Kostic, Karl Aberer:
Improving the Throughput of Distributed Hash Tables Using
Congestion-Aware Routing. International Workshop on Peer-to-Peer
Systems (IPTPS'07), Bellevue, WA, USA, February 26.-27, 2007
(available online at
http://lsirpeople.epfl.ch/klemm/Improving%20the%20Throughput%20of%20Distributed%20Hash%20Tables%20Using%20Congestion-Aware%20Routing.pdf)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Lars Eggert <[email-masked]>
Date: Sat, 7 Jun 2008 16:25:14 +0200

Hi,

>    operators that provide connectivity to those peers"?

the idea is that applications than make intensive use of the network  
may be interested in choosing all or some of their peers (servers,  
caches, end hosts) based on or at least influenced by recommendations  
from the network. It remains to be defined what kinds of information  
those recommendations will exactly convey; proposals seem to include  
performance-related information, topology-related information, etc.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 7 Jun 2008 16:34:14 +0200

Hi,

On 2008-6-6, at 16:34, ext Michael Welzl wrote:
>>     interference with regular best-effort traffic.
>

there does seem to be interest from at least part of the bulk-transfer- 
app community in such a feature, and AFAIK Microsoft also uses  
something similar for WindowsUpdate.

The fact that there's been quite a bit of solid research work on this  
topic over the years makes me confident that we could actually do  
standardization in this space relatively quickly.

> To look at the complementary side of things, is anyone actually

Not that I know of, which is why folks are interested in mechanisms  
that can be deployed on end-systems only. (RFC3662 is "A Lower Effort  
Per-Domain Behavior (PDB) for Differentiated Services", FYI.)

> deploy it on, but how do we get people to use these things?

Like Hannes said, there does seem to be some interest already.

Lars

---

From: "Michael Welzl" <[email-masked]>
Date: Sat, 7 Jun 2008 18:45:13 +0200

> something similar for WindowsUpdate.

I wasn't aware of that, but it's great!

> Like Hannes said, there does seem to be some interest already.

Yep, cool - I also wasn't aware of BitTorrent efforts

I'm a big fan of lower-than-best-effort ideas - I think there
could be a ton of great services based on that ... I dream
of an Internet where no lines are empty, and everything is
filled with "background radiation", of traffic that would
quickly give way to anything else, yet contain some potentially
useful data, e.g. for caching, prefetching etc

I recently encountered one more practical problem with
this, though. We carried out measurements from one of
our University's computers, and received a complaint from
the IT service dept because of the heavy load we're causing.
I told them not to worry, "it's only TCP" - they said that
it doesn't matter how (non-)aggressive my traffic is, the
number of bytes traversing their link is counted, and if
the monthly average significantly rises, they pay more

It's a sort of averaged load-based charging - such a service
model is quite at odds with thoughts of "background radiation",
and will hopefully disappear as such lower-than-BE mechanisms
become deployed (or we need devices which attempt to better
classify traffic per aggression - probably not easy to do)

Anyway, this doesn't contribute to the discussion, it's just
something that I found interesting. I agree that standardizing
such a mechanism would be good.

Cheers,
Michael

---

From: Michael Scharf <[email-masked]>
Date: Sat, 7 Jun 2008 20:06:17 +0200

> > something similar for WindowsUpdate.

I recently noticed that the "Adobe Updater" (at least version 8 for
windows) also has a feature of this kind: It can be configured to
download data only if the network connection is idle. 

But the realization seems to be very rudimentary. The client program
probably somehow mirrors the local network card and interrupts the
download if there is some activity. But it is apparently unable to
detect any competing cross-traffic to another host behind the same
bottleneck, i. e., it is worthless in many usage scenarios.

This might be yet another indication that guidelines are needed how to
realize such a feature correctly.

Michael

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 7 Jun 2008 21:43:38 +0300

Hello there,

> something similar for WindowsUpdate.

I'm curious to know how this can be done at the client side. AFAIK Microsoft 
uses Akamai for its Windows Updates and thus it isn't possible to deploy such 
a custom TCP implementation at the sending side. Perhaps I am wrong and 
Akamai supports a low-traffic / idle time TCP variant like Aleksandar 
Kuzmanovic's Low-Priority TCP (TCP-LP) that Linux supports?

---

From: Lars Eggert <[email-masked]>
Date: Sun, 8 Jun 2008 12:17:00 +0200

Hi,

> useful data, e.g. for caching, prefetching etc

I agree with you. Not surprising, since I've done some work on this in  
the past; my dissertation was on "background use of idle network  
capacity" (not just network, many resources). If you're interested,  
the stuff is online at http://people.nokia.net/~lars/papers.html with  
this pub probably the most comprehensive one: Idletime Scheduling with  
Preemption Intervals. Lars Eggert and Joe Touch. Proc. 20th ACM  
Symposium on Operating Systems Principles (SOSP 2005), Brighton,  
United Kingdom, October 23-26, 2005, pp. 249-262, http://people.nokia.net/~lars/papers/f109-eggert.pdf 
.

The need for this came out of the LSAM project at ISI (http://www.isi.edu/lsam/ 
), which used multicast to speculatively push out hot content to a  
network of distributed web caches, and hence generated quite a bit of  
traffic that lead to similar problems we're now seeing with P2P. So we  
needed something to treat that bulk of multicast traffic as less-than- 
best-effort.

(Full disclosure: I have no interest in pushing this scheduling  
solution, I'm just bringing it up as related work.)

> the monthly average significantly rises, they pay more

Right; what's missing is differentiated charging. Less-than-best- 
effort traffic should be cheap or free compared to regular best-effort- 
traffic.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Sun, 8 Jun 2008 12:18:17 +0200

On 2008-6-7, at 20:43, ext Stefanos Harhalakis wrote:
> I'm curious to know how this can be done at the client side.

For TCP, you can shrink your announced window or fake losses.

Lars

---

From: "Michael Welzl" <[email-masked]>
Date: Sun, 8 Jun 2008 13:02:51 +0200

> For TCP, you can shrink your announced window or fake losses.

...and they really do that?? 

Cheers,
Michael

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 8 Jun 2008 07:36:52 -0400

On Jun 7, 2008, at 10:34 AM, Lars Eggert wrote:

> there does seem to be interest from at least part of the bulk- 
> transfer-app community in such a feature, and AFAIK Microsoft also  
> uses something similar for WindowsUpdate.
>
> The fact that there's been quite a bit of solid research work on  
> this topic over the years makes me confident that we could actually  
> do standardization in this space relatively quickly.
>

As I have stated before, the eVLBI community would be very interested  
in this. On a deeper level, I think that
wide uses for such capabilities should develop. Anytime you are  
sending data with a low signal to noise ratio, you are likely to want  
to send as many bits as possible. Once you are in that regime, it  
doesn't really make sense to use bandwidth to replace lost bits - you  
might as well just send new bits instead.

I would be interested in any meetings in Dublin on this topic.

Regards
Marshall
> that can be deployed on end-systems only. (RFC3662 is "A Lower  
> Effort Per-Domain Behavior (PDB) for Differentiated Services", FYI.)
>

---

From: Joe Touch <[email-masked]>
Date: Sun, 08 Jun 2008 10:42:28 -0700

Lars Eggert wrote:
> capacity" (not just network, many resources). If you're interested, the 
> stuff is online at http://people.nokia.net/~lars/papers.html with this 
> pub probably the most comprehensive one: Idletime Scheduling with 
> Symposium on Operating Systems Principles (SOSP 2005), Brighton, United 
> Kingdom, October 23-26, 2005, pp. 249-262, 
> http://people.nokia.net/~lars/papers/f109-eggert.pdf.
> 
> The need for this came out of the LSAM project at ISI 
> (http://www.isi.edu/lsam/), which used multicast to speculatively push 
> out hot content to a network of distributed web caches, and hence 
> generated quite a bit of traffic that lead to similar problems we're now 
> seeing with P2P. So we needed something to treat that bulk of multicast 
> traffic as less-than-best-effort.
> 

FWIW, the LSAM stuff may be of relevance as well; as I noted, there 
appears to be a lot of similarity between hierarchical web pushing (on 
which there is a body of literature) and P2P interaction optimization. 
That work occurred in the mid 1990's.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 09 Jun 2008 06:58:52 +0100

Michael,

>[MW] Anyway, this doesn't contribute to the discussion, it's just

[BB] I agree too - I'm willing to help.

Your last thought wasn't a side-issue to the discussion at all (quoting) ...

>[MW] received a complaint from
>number of bytes traversing their link is counted

[BB] No - it was right on-topic. This issue is all about how the 
goals of TCP and of network operations people /both/ fall short in 
different ways, because they each care about different but incomplete metrics.

The combined metric that both sides would be happy with (see below) 
would also encourage your background radiation (scavenger) dream to 
happen. This metric is trivial for the endpoint to measure, but 
unfortunately hard for a network to monitor.

We will need to resolve this when standardising scavenger solutions 
as, otherwise scavenger traffic users will get caught up in an arms 
race against /each other/. The outcome will escalate up back where we 
started, with background competing against foreground traffic again.

The required per-user metric your operations people really care 
about, but can't measure easily, is neither congestion alone, nor 
volume alone, but 'congestion-volume'. Counting bytes alone gives no 
incentive for background traffic to fill the troughs in congestion. 
Volume needs to be weighted by the congestion at each moment. The answer is:
         volume x path congestion when volume sent

                 path congestion can be measured by the loss fraction, giving:
         volume [B] x loss fraction [%] when volume sent
         =  discarded volume [B]    (or, with ECN, it would be marked bytes).

This is 'congestion-volume'.

The 3page paper I presented at the p2pi workshop made the case for 
this metric, in order to self-enforce your background radiation 
scenario - whether driven by e2e congestion control or Diffserv or a 
mix of both. Here it is with slides:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>

Bob

>such a mechanism would be good.

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Michael Welzl <[email-masked]>
Date: Mon, 09 Jun 2008 08:07:27 +0200

> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>

Thanks! This looks really interesting, and I totally agree about
the value of such a metric.

In practice, I think it'll look too complicated for many
operations people at first sight, but then again it's
always worth a try to change people's mindsets...

Are you planning to write a draft on this? (and sorry if
you already did, or included it in another one, and I
overlooked it - it's easy to overlook something among
the many things you're doing  :)   )  I think that this
sort of recommendation would be good to have published.

Cheers,
Michael

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 9 Jun 2008 16:40:07 -0400

The proposal for the ALTO BoF (which roughly covers (3)) is now in the
BoF tracker. You can read about it at its home page:

http://alto.tilab.com/

ALTO proposes to explore a slightly broader space than merely P2P
file-sharing applications, since discovery of nearby peers has equal
applicability to many real-time communications protocols (for example,
the discovery of a TURN server to assist the establishment of a VoIP
session). Although RAI proposes to sponsor a BoF on this subject, we're
not yet persuaded that RAI would be the optimal home for any ongoing
work efforts related to this space - we hope that discussions
surrounding the BoF could elucidate the proper division of labor and
approach to this problem.

I do believe this work effort is sufficiently distinct from the
transport issues discussed in (1) and (2) of Lars' original mail to
merit a separate effort. I do, however, whole-heartedly support TSV
taking on (1) and (2) in a forum like TANA. 

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars Eggert
Sent: Friday, June 06, 2008 7:41 AM
To: TSV Area
Cc: [email-masked]; [email-masked] IAB; [email-masked]; IESG ((E-mail));
P2PSIP Mailing List
Subject: Re: discussing P2PI-related standardization in Dublin

Hi,

Lars

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 9 Jun 2008 17:01:41 -0400

Exceptionally minor comments inline.

> take on some or all of these, and if so, whether TSV would be 
> the right place for this work.

A BoF or two would be good, IMHO.  Some of this probably fits into TSV
too, so confiming that this seems on the right track to me at least.

> Networking Applications" or TANA. 

So far we have TANA and ALTO, plus referring some items into TSV, which
again, seems appropriate and useful.  I do not have anything else to add
to this list for now; perhaps discussion @ IETF-72 will reveal further
needs.

Jason

---

From: Lars Eggert <[email-masked]>
Date: Fri, 13 Jun 2008 19:39:35 +0300

Hi,

> seen yet), work item (3) might be subsumed by it.

this BOF proposal has now materialized in form of ALTO (http://alto.tilab.com/ 
), a BOF proposal targeted at APP and RAI.

It's hence somewhat likely that we may have a TANA BOF in TSV that  
focuses on the work items (1) and (2) from my original email, and a  
second ALTO BOF hosted by APP and RAI.

(Note: this email is *not* an IESG approval of either the TANA or ALTO  
BOF - those will come from the responsible ADs if and when they come.)

ALTO is currently scoped a bit more broadly than the TANA work item  
(3) was, and some of the broader proposals in the ALTO space could  
lead to significant transport issues. A fraction of the ALTO  
proponents argues to exchange information related to end-to-end  
performance (bandwidth, RTT, congestion, transfer time estimates,  
etc.) through the oracle, for example.

I'd like to ask transport folks to participate in the discussion on  
ALTO on the [email-masked] mailing list, in order to discuss the  
transport implications of the various ALTO ideas.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Jun 2008 11:24:26 +0300

On 2008-6-14, at 3:16, ext Richard Bennett wrote:
> Do we have a date for the proposed BOF in Dublin?

Not yet. I've approved TANA (with work items 1 and 2 from the original  
email), but ALTO needs the approval of the ADs for the areas it was  
submitted to.

> Lars Eggert wrote:
>> (Note: this email is *not* an IESG approval of either the TANA or  
>> ALTO  BOF - those will come from the responsible ADs if and when  
>> they come.)

Lars