Subject: [tsv-area] TANA proposed charter

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 06:17:09 -0700

At the BoF in Dublin, we observed strong interest and consensus that  
the TANA work should go forward as a working group.  Does the  
following proposed charter, based on the BoF description, capture what  
the community was interested in?

Thanks,  -- Stas

Techniques for Advanced Networking Applications (TANA) WG

Chair(s):
TBD

Transport Area Director(s):
* Magnus Westerlund <[email-masked]>
* Lars Eggert <[email-masked]>

Transport Area Advisor:
* Lars Eggert <[email-masked]>

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/tana/

Description of Working Group:

The TANA WG is chartered to standardize a congestion control mechanism  
that should saturate the bottleneck, maintain low delay, and yield to  
standard TCP.

Applications that transmit large amounts of data for a long time with  
congestion-limited TCP, but without ECN fill the buffer at the head of  
the bottleneck link. This increases the delay experienced by other  
applications. In the best case, with an ideally sized buffer of one  
RTT, the delay doubles. In some cases, the extra delay may be much  
larger. This is a particularly acute and common case is when P2P  
applications upload over thin home uplinks: delays in these cases can  
sometimes be of the order of seconds.

The IETF's standard end-to-end transport protocols have not been  
designed to minimize the extra delay introduced by them into the
network. TCP, as a side effect of filling the buffer until it  
experiences drop-tail loss, effectively maximizes the delay. While  
this works well for applications that are not delay-sensitive, it  
harms interactive applications that share the same bottleneck. VoIP  
and games are particularly affected, but even web browsing may become  
problematic.

TANA is a transport-area WG that will focus on broadly applicable  
techniques that allow large amounts of data to be consistently  
transmitted without substantially affecting the delays experienced by  
other users and applications.

The WG will work on the following:

(1) An experimental 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.

Desired features of such an algorithm are:
* saturate the bottleneck,
* eliminate long standing queues and thus keep delay low when no other  
traffic is present,
* quickly yield to regular best-effort traffic that uses standard TCP  
congestion control,
* add little to the queueing delays induced by TCP traffic,
* operate well in today's typical networks with FIFO queueing with  
drop-tail discipline,
* where available, use explicit congestion notification (ECN), active  
queue management (AQM), and/or end-to-end differentiated services  
(DiffServ).

Application of this algorithm to existing transport protocols (TCP,  
SCTP, DCCP) is expected to occur in the working groups that maintain  
those protocols.

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

Standard Internet congestion control result in different transport  
connections sharing bottleneck capacity. When an application uses  
several unchoked and not rate-limited transport connections to  
transfer through a bottleneck, it may obtain a larger fraction of the  
bottleneck than if it had used fewer connections. Although capacity is  
the most commonly considered bottleneck resource, middlebox state  
table entries are also an important resource for an end system  
communication. Other resource types may exist, and the guidelines are  
expected to comprehensively discuss them.

Applications use a variety of techniques to mitigate these concerns.   
These techniques have not always been reviewed by the IETF and their  
interaction with TCP dynamics is poorly understood.  The WG document  
the known techniques, discussing the consequences and, where  
appropriate, provide guidance to application designers.

(3) The WG will discuss how to best take into account prior work in  
the area.  The outcome will be either incorporated into the document  
specifying the experimental congestion control algorithm or into a  
separate document summarizing prior work.

Goals and Milestones

TBD  Submit "Multiple Transport Connections in Applications Design" to  
the IESG for consideration as an Informational RFC
TBD  Submit "Transport for Advanced Networking Applications (TANA)" to  
the IESG for consideration as an Experimental RFC

Internet-Drafts

Transport for Advanced Networking Applications (TANA) Problem Statement
http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt

No Requests for Comments

--
Stanislav Shalunov

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Tue, 21 Oct 2008 09:12:10 -0500

The charter, as written looks reasonable to me.  I just hate the name
:).

Even though you explained it before, "Advanced Network Applications"
still bothers me as it's completely unspecific.  Furthermore, I think
that "Techniques" isn't well-scoped enough to limit the work properly
as it seems to be focused on congestion control techniques, and not
NAT traversal techniques, search techniques, etc.

The way that the problem statement was described, I think what's really
meant is "bulk transfer applications that want to be a good neighbor to
real-time or other applications".  I guess the challenge is that this
doesn't produce a pronouncable acronym like TANA :).

It should really be something like:
"Minimizing Impact of Large Transfers" (MILT)
"Concurrent Realtime And Bulk Applications" (CRABA)
"Fast Transfers Adding Minimal Latency" (FTAML)
"Bulk And Realtime Flows Interacting as Good Neighbors" (BARFIGN) --
probably not a good one as it looks too much like "barfing" :)

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!

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Stanislav Shalunov
>Sent: Tuesday, October 21, 2008 9:17 AM
>To: [email-masked]; [email-masked]; TSV Area
>Subject: [tsv-area] TANA proposed charter
>
>At the BoF in Dublin, we observed strong interest and 
>consensus that the TANA work should go forward as a working 
>group.  Does the following proposed charter, based on the BoF 
>description, capture what the community was interested in?
>
>Thanks,  -- Stas
>
>
>
>The TANA WG is chartered to standardize a congestion control 
>mechanism that should saturate the bottleneck, maintain low 
>delay, and yield to standard TCP.
>
>Applications that transmit large amounts of data for a long 
>time with congestion-limited TCP, but without ECN fill the 
>buffer at the head of the bottleneck link. This increases the 
>delay experienced by other applications. In the best case, 
>with an ideally sized buffer of one RTT, the delay doubles. In 
>some cases, the extra delay may be much larger. This is a 
>particularly acute and common case is when P2P applications 
>upload over thin home uplinks: delays in these cases can 
>The IETF's standard end-to-end transport protocols have not 
>been designed to minimize the extra delay introduced by them into the
>experiences drop-tail loss, effectively maximizes the delay. 
>While this works well for applications that are not 
>delay-sensitive, it harms interactive applications that share 
>the same bottleneck. VoIP and games are particularly affected, 
>but even web browsing may become problematic.
>
>TANA is a transport-area WG that will focus on broadly 
>applicable techniques that allow large amounts of data to be 
>consistently transmitted without substantially affecting the 
>delays experienced by other users and applications.
>
>(1) An experimental 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.
>
>* eliminate long standing queues and thus keep delay low when 
>no other traffic is present,
>* quickly yield to regular best-effort traffic that uses 
>standard TCP congestion control,
>* operate well in today's typical networks with FIFO queueing 
>with drop-tail discipline,
>* where available, use explicit congestion notification (ECN), 
>active queue management (AQM), and/or end-to-end 
>differentiated services (DiffServ).
>
>Application of this algorithm to existing transport protocols 
>(TCP, SCTP, DCCP) is expected to occur in the working groups 
>that maintain those protocols.
>
>(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.
>
>Standard Internet congestion control result in different 
>transport connections sharing bottleneck capacity. When an 
>application uses several unchoked and not rate-limited 
>transport connections to transfer through a bottleneck, it may 
>obtain a larger fraction of the bottleneck than if it had used 
>fewer connections. Although capacity is the most commonly 
>considered bottleneck resource, middlebox state table entries 
>are also an important resource for an end system 
>communication. Other resource types may exist, and the 
>guidelines are expected to comprehensively discuss them.
>
>Applications use a variety of techniques to mitigate these 
>concerns.  These techniques have not always been reviewed by 
>the IETF and their interaction with TCP dynamics is poorly 
>understood.  The WG document the known techniques, discussing 
>the consequences and, where appropriate, provide guidance to 
>application designers.
>
>(3) The WG will discuss how to best take into account prior 
>work in the area.  The outcome will be either incorporated 
>into the document specifying the experimental congestion 
>control algorithm or into a separate document summarizing prior work.
>
>
>
>Goals and Milestones
>
>TBD  Submit "Multiple Transport Connections in Applications 
>Design" to the IESG for consideration as an Informational RFC
>TBD  Submit "Transport for Advanced Networking Applications 
>(TANA)" to the IESG for consideration as an Experimental RFC
>
>
>Internet-Drafts
>
>Stanislav Shalunov <http://shlang.com/> 
>
>Hacking Startups <http://feeds.feedburner.com/~r/shlang/~6/1> 
>
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Oct 2008 11:00:42 -0400

Hi,

> The charter, as written looks reasonable to me.  I just hate the name

the name was an ad hoc creation, and when it was picked, some of the  
stuff that ended up being ALTO was part of the TANA scope - so it  
needed to be broader.

If we can come up with a better name I'm all ears (and you make  
several good suggestions below). What I'd like to avoid is a long  
discussion about a text string, when what I'd rather like to see is a  
discussion on whether the work we're going to attempt is reasonable.

Lars

> probably not a good one as it looks too much like "barfing" :)

I'm pretty sure CRABA would also have interesting soundex matches...

---

From: Bruce Davie <[email-masked]>
Date: Tue, 21 Oct 2008 11:06:07 -0400

I'll start by saying that I support the WG and think the new charter  
is pretty good. I have a few suggestions for small changes.

> buffer at the head of the bottleneck link.

Replace ECN with Active Queue Management (AQM)

> This increases the
> delay experienced by other applications.

It would be more accurate to say "In the absence of any form of  
isolation in the queues, this increases..."

> In the best case,
> some cases, the extra delay may be much larger.

Since there isn't complete agreement on the ideal size of a buffer,  
just say:

"If the buffer size is one RTT, the delay doubles...."

> This is a
[snip]

> standard TCP congestion control,

perhaps it would be more precise to say:
"quickly yield to traffic sharing the same bottleneck queue that uses  
standard TCP congestion control"

> with drop-tail discipline,

suggest deleting "today's typical"

> differentiated services (DiffServ).
[snip]

> connections to one peer and/or to different peers.

This is just a bit confusingly worded and could be interpreted very  
broadly. I would suggest:
"(2) A document that discusses the
tradeoffs surrounding the use of many concurrent transport
connections to one peer and/or to different peers and recommends best  
practices for applications in this regard."

Finally, I hate the name, because it is so completely undescriptive of  
the WG. I like all of Wesley's suggestions better, MILT probably being  
the best.

Bruce

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2008 08:40:18 -0700

Lars Eggert wrote:
> stuff that ended up being ALTO was part of the TANA scope - so it needed
> to be broader.
> 
> If we can come up with a better name I'm all ears (and you make several
> good suggestions below). What I'd like to avoid is a long discussion
> about a text string, when what I'd rather like to see is a discussion on
> whether the work we're going to attempt is reasonable.
> 
> Lars
> 

FWIW, it seems like "background TCP" is what you want (BTCP); granted,
that's already a spec'd protocol ;-)

Maybe, more generally, Background Congestion Control (BACK-CC)?

Joe

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Oct 2008 12:00:37 -0400

On Oct 21, 2008, at 11:40 AM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Lars Eggert wrote:
>> Hi,
>>
>> needed
>> several

Background Congestion Control of File Flows (BACK-OFF) ?

Regards
Marshall

>
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkj99+EACgkQE5f5cImnZrvY9ACgxGAeY/J4lMtZvxEht+/gxdfx
> KDUAniB8eeoRz0Z4HDyDBCGbKAHtAVvn
> =KTqj
> -----END PGP SIGNATURE-----
> _______________________________________________
> tana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tana

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 21 Oct 2008 09:05:02 -0700

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars Eggert
Sent: Tuesday, October 21, 2008 11:01 AM
To: ext Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: TSV Area; [email-masked]; [email-masked]
Subject: Re: [tsv-area] TANA proposed charter

Hi,

Lars

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 21 Oct 2008 09:23:01 -0700

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"

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2008 09:23:04 -0700

> On Oct 21, 2008, at 11:40 AM, Joe Touch wrote:
...
>> Background Congestion Control of File Flows (BACK-OFF) ?

Maybe omit 'file' (there could be utility to non-file background
transfers), i.e.:

	Backgrounds OF Flows (BACK-OFF)

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Oct 2008 09:32:06 -0700

Overall, I like the charter.

The one problem I have, however, is not technical but the economic  
model.

One can do a fairly decent (not great, but OK) approximation today by  
using a delay-based (eg, TCP-vegas) congestion control, as its  
designed to minimize queues and tends to get outcompeted by TCP reno  
(the two big-desired).

Especially since intuition suggests that you could do this "single- 
ended", have the TCP stack on ONE side do delay-based estimation in  
both directions, and request window resizing to control the other  
side's sending rate.

Yet why would a bulk-data content provider want to USE it?

If the business model is "Video or other bulk data NOW", you don't  
want it friendlier than TCP, you only want to make sure you don't kill  
the queues on a customer's access device (if P2P).  Thus the goal is  
ONLY to minimize queues, because being friendlier than TCP otherwise  
might get your data squeezed out in the rest of the network.

If anything, you might want to be more HOSTILE, because you have a  
minimum aggregate data rate (averaged out over say 10-30 seconds of  
buffer) you need to keep a realtime display going.

If the business model is "Video or other bulk data OVERNIGHT", then  
you are competing with the US Postal Service for legal content, which  
is pretty darn cheap for bandwidth.

I'd really like a "Less Than Best Effort" data class/congestion  
control that does not populate queues and yields completely (on the  
order of a couple of RTTs) to conventional TCP.  But I really wonder  
who'd use it?

> Replace ECN with Active Queue Management (AQM)

I'd actually say "ECN or Active Queue Management"

> "If the buffer size is one RTT, the delay doubles...."

Especially since the bottleneck devices in question are sometimes  
obscenely overbuffered.

> "quickly yield to traffic sharing the same bottleneck queue that  
> uses standard TCP congestion control"

One question is "How MUCH yielding".  Should the nicer-than-TCP flow  
go to 0?  Or should there be some equilibrium value (eg, with 2 flows,  
one TCP, one friendly-bulk-data, should it be something like 75/25?)

---

From: Ted Faber <[email-masked]>
Date: Tue, 21 Oct 2008 09:50:51 -0700

> 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

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 10:06:48 -0700

On Oct 21, 2008, at 9:32 AM, Nicholas Weaver wrote:

> One can do a fairly decent (not great, but OK) approximation today  
> by using a delay-based (eg, TCP-vegas) congestion control, as its  

This is a great question and it deserves a more detailed answer than  
this, but let me try, briefly, to provide one reason to use it:

Because the user wants to use the Internet while P2P app is doing  
whatever it is doing.  Or the user will uninstall the app.

The content provider serves at the leisure of the user.  The user is  
willing to share uplink capacity as long as the sharing is largely  
invisible.  The user will be upset by uploads that affect the user's  
ability to use the network for interactive applications and web  
browsing.

(There are other scenarios, particularly with shared congestion and  
traffic management, that generally push the content provider to be  
nicer, so the above is just one example.)

-- Stas

> want it friendlier than TCP, you only want to make sure you don't  
> kill the queues on a customer's access device (if P2P).  Thus the  
> goal is ONLY to minimize queues, because being friendlier than TCP  
> otherwise might get your data squeezed out in the rest of the network.
>
> you are competing with the US Postal Service for legal content,  
> which is pretty darn cheap for bandwidth.
>
>
>> I'll start by saying that I support the WG and think the new  
>> charter is pretty good. I have a few suggestions for small changes.
>>
> go to 0?  Or should there be some equilibrium value (eg, with 2  
> flows, one TCP, one friendly-bulk-data, should it be something like  
> 75/25?)
>
>
> p2pi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2pi

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 10:11:37 -0700

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

--
Stanislav Shalunov

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 10:25:26 -0700

On Oct 21, 2008, at 10:20 AM, Salman Abdul Baset wrote:
> The general recommendation by VoIP providers is to manually shutdown  
> the p2p application(s) so as not to affect the calls. This manual  
> shutdown is quite annoying for a user.

Yep.

This shutdown is a form of crude and manual congestion control, where  
the user moves the dial that the computer should be moving.

Another example of that are max upload/download limits that P2P users  
are routinely expected to set if they want to use the net while  
running the app.

--
Stanislav Shalunov

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 21 Oct 2008 13:20:42 -0400 (EDT)

> This is a great question and it deserves a more detailed answer than this, 
> but let me try, briefly, to provide one reason to use it:
>
> Because the user wants to use the Internet while P2P app is doing whatever it 
> is doing.  Or the user will uninstall the app.

To add:

Some traffic is more important than others. A rough ordering is:
VoIP > interactive > video-streaming > file-transfer > p2p

The general recommendation by VoIP providers is to manually shutdown the 
p2p application(s) so as not to affect the calls. This manual shutdown is 
quite annoying for a user.

-s

> The content provider serves at the leisure of the user.  The user is willing 
> to share uplink capacity as long as the sharing is largely invisible.  The 
> user will be upset by uploads that affect the user's ability to use the 
> network for interactive applications and web browsing.
>
> (There are other scenarios, particularly with shared congestion and traffic 
> management, that generally push the content provider to be nicer, so the 
> above is just one example.)
>
> -- Stas
>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Oct 2008 10:41:46 -0700

> nicer, so the above is just one example.)

However, the "Internet Not Working" effect is a subpiece of the  
overall problem:  It is buffer occupancy on end-user buffers where the  
buffers are on the order of 1+ RTT (often 1+ Second!).   Otherwise,  
the incentives are to be as UN-friendly as possible, as the  
externalities of congestion, EXCEPT at the access-link device, are  
applied to other users.

Thus the P2P application provider can use existing RTT-based  
congestion control techniques to look for a greater than .25 RTT  
increase in delay, and respond to it by shrinking window sizes until  
the RTT drops and at-that-point, call it good.

In fact, simply feed this into bandwidth estimation:  Do an initial  
uncongested bandwidth estimation on startup (packet-pair measurement)  
to other peers (eliminates the "select a bandwidth" checkbox, bonus!),  
attempt to allocate to the whole pipe-5% with your TCP flows, and do  
an immediate backoff/slow ramp-back when you see RTTs increasing to  
MULTIPLE peers.

Although a new class of congestion control that would do a true end-to- 
end job would be a better solution, the partial solution is complete  
from the P2P application provider's viewpoint: it fixes the "We break  
the net for everything else" effect on the user, while still keeping  
the very agressive (many-flow TCP) properties of P2P for the rest of  
the network.

Or at least until you bribe the NAT box vendors to implement some  
active queue management.

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 21 Oct 2008 11:19:34 -0700

On Oct 21, 2008, at 10:41 AM, Nicholas Weaver wrote:
>  do an immediate backoff/slow ramp-back when you see RTTs increasing  
> to MULTIPLE peers.

Very true, and a special case of more general, and applicable to TCP,  
etc.:

Any delay-based congestion control can be modified to key off the min  
delay to multiple peers, effectively ignoring far-away congestion.
Any loss-based congestion control can be modified to key off the min  
loss to multiple peers, effectively ignoring far-away congestion.

Any congestion control based on a numeric measure of congestion can be  
modified to key off the min measure of congestion to multiple peers,  
effectively ignoring far-away congestion.

("Far-away" = beyond the point of divergence of paths of the different  
flows.)

In practice, I don't believe there are interesting benefits for doing  
so for P2P apps.  For swarms that have a fighting chance, even the  
nicest behaviors yield excellent results.  The main reason to get poor  
results is very small swarm size.

Regardless -- congestion control on the Internet is done by  
endpoints.  In the end-to-end framework, we can't do very much about  
noncooperative endpoints, but, luckily for us, there are relatively  
few of those.

Making the congestion control mechanisms of cooperative endpoints more  
suitable for their goals can yield great benefits.  Most P2P apps want  
to be cooperative as far as congestion control goes.  In fact, you  
don't often see non-P2P apps that come with the expectation that users  
will manually set the right rate limits on them and prominently  
accessible UI for doing so.  (The point of these rate limits is, of  
course, to send at a rate lower than would normally be produced by the  
nicest of congestion control mechanisms.)

Thank you,
--
Stanislav Shalunov

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Oct 2008 11:33:26 -0700

I'll start by saying that I do like the charter and believe that it is scoped correctly.  

I do, however, share some of the concerns that Nicholas has raised.  We are talking about bulk data p2p transfers here, not necessarily just limited to file transfers.  This does mean p2p models of video, games that exchange large amounts of data (e.g., World of Warcraft), large medical data (e.g., high resolution imaging) transfer, etc. fall into this category.  Of course, for some of these applications, the answer may simply be that TANA is not applicable and hence, should not be used.  However, I do think there are more grades to this. 

Another interesting piece of data is that for the first time in many years, http has overtaken p2p traffic in some markets, primarily driven by video download applications such as YouTube.  Thanks to http being the common firewall transport mechanism, much of the video now runs over TCP.  So, is it really as cut and dry as the bulk data P2P traffic needing to yield to Internet traffic?  As long as it is about some background file transfer, perhaps that philosophy will just work.  But, if the P2P app is also a video app, the answer is probably more complex. 

There is no doubt that this charter is attempting to tackle a very important issue.  But, it would be good to think about what grades we may need to address here.  

Regards,
Vidya

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Nicholas Weaver
> Sent: Tuesday, October 21, 2008 10:42 AM
> To: Stanislav Shalunov
> Cc: [email-masked]; Nicholas Weaver; [email-masked]; TSV Area; 
> Bruce Davie; Eddy, Wesley M. (GRC-RCN0)[VZ]
> Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter
> 
> 
> However, the "Internet Not Working" effect is a subpiece of 
> the overall problem:  It is buffer occupancy on end-user 
> buffers where the  
> externalities of congestion, EXCEPT at the access-link 
> device, are applied to other users.
> 
> congestion control techniques to look for a greater than .25 
> RTT increase in delay, and respond to it by shrinking window 
> sizes until the RTT drops and at-that-point, call it good.
> 
> In fact, simply feed this into bandwidth estimation:  Do an 
> initial uncongested bandwidth estimation on startup 
> (packet-pair measurement) to other peers (eliminates the 
> "select a bandwidth" checkbox, bonus!), attempt to allocate 
> to the whole pipe-5% with your TCP flows, and do an immediate 
> backoff/slow ramp-back when you see RTTs increasing to MULTIPLE peers.
> 
> Although a new class of congestion control that would do a 
> true end-to- end job would be a better solution, the partial 
> solution is complete from the P2P application provider's 
> viewpoint: it fixes the "We break the net for everything 
> else" effect on the user, while still keeping the very 
> agressive (many-flow TCP) properties of P2P for the rest of 
> the network.
> 
> Or at least until you bribe the NAT box vendors to implement 
> some active queue management.
>

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Oct 2008 11:50:44 -0700

On Oct 21, 2008, at 11:33 AM, Narayanan, Vidya wrote:

> I do, however, share some of the concerns that Nicholas has raised.   
> We are talking about bulk data p2p transfers here, not necessarily  
> just limited to file transfers.  This does mean p2p models of video,  
> games that exchange large amounts of data (e.g., World of Warcraft),  
> large medical data (e.g., high resolution imaging) transfer, etc.  
> fall into this category.  Of course, for some of these applications,  
> the answer may simply be that TANA is not applicable and hence,  
> should not be used.  However, I do think there are more grades to  
> this.

Well, it also depends too:

The medical data is point to point, not P2P.  A single TCP flow works  
well, and by being on real network, shouldn't experience the buffer  
issues present in home gateways, and by being a single flow, doesn't  
have the congestion-monopolization properties that P2P transfer  
programs have.

Warcraft is not using P2P for playing, rather it is using P2P to save  
money in the data transfer of "patches", which include large amounts  
of content (textures, models, etc) (thus my rant on cost shifting).

> Another interesting piece of data is that for the first time in many  
> years, http has overtaken p2p traffic in some markets, primarily  
> driven by video download applications such as YouTube.  Thanks to  
> http being the common firewall transport mechanism, much of the  
> video now runs over TCP.  So, is it really as cut and dry as the  
> bulk data P2P traffic needing to yield to Internet traffic?  As long  
> as it is about some background file transfer, perhaps that  
> philosophy will just work.  But, if the P2P app is also a video app,  
> the answer is probably more complex.

Additionally, on the video apps, to my mind these are often badly  
done, and badly done in a way that the transport layer can do nothing  
about.

Take YouTube for example.  Its flash-based structure is not suitable  
(deliberately so!) for significant offline viewing.  Yet its buffer  
strategy is "Fill-er-up completely", when many viewers will not stick  
around to watch the whole thing: a substantial waste although it does  
improve seek time.

(Comedy Central's, OTOH, has a maximum buffer of about 10 seconds, so  
"stop in the middle" doesn't waste bandwidth).

Yet all of these apps don't also properly recognize "I don't have  
ENOUGH bandwidth to keep up with realtime", and so don't (aren't  
capable of in flash?) of switching to a lower-bitrate encoded source.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Oct 2008 14:53:22 -0400

Hi,

the goal for TANA and ALTO was to identify some subsets of the overall  
problem space that are sufficiently well understood that we can start  
to architect solutions. (And limit ourselves to those subsets where  
the IETF would be an appropriate body for this work.)

There are certainly other parts of this problem that may be ripe for  
discussion in the IETF, and chartering TANA and ALTO by no means  
precludes this discussion from happening. I fully expect the IETF to  
take on additional work related to this general problem space in the  
future - we just had to start somewhere, and TANA and ALTO is where we  
started.

I'd strongly encourage folks that want to push forward additional  
proposals for the IETF to take on in this space!

Lars

On 2008-10-21, at 14:33, ext Narayanan, Vidya wrote:
> There is no doubt that this charter is attempting to tackle a very  
> important issue.  But, it would be good to think about what grades  
> we may need to address here.
>
> Regards,
> Vidya

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Oct 2008 12:10:06 -0700

I support this WG and intend to submit a draft on P2P multiple connections
before the deadline.

Thanks,

Reinaldo

On 10/21/08 6:17 AM, "Stanislav Shalunov" <[email-masked]> wrote:

> At the BoF in Dublin, we observed strong interest and consensus that the TANA
> work should go forward as a working group.  Does the following proposed
> charter, based on the BoF description, capture what the community was
> interested in?
> 
> Thanks,  -- Stas
> 
> 
> 
> The TANA WG is chartered to standardize a congestion control mechanism that
> should saturate the bottleneck, maintain low delay, and yield to standard TCP.
> 
> congestion-limited TCP, but without ECN fill the buffer at the head of the
> bottleneck link. This increases the delay experienced by other applications.
> In the best case, with an ideally sized buffer of one RTT, the delay doubles.
> In some cases, the extra delay may be much larger. This is a particularly
> acute and common case is when P2P applications upload over thin home uplinks:
> delays in these cases can sometimes be of the order of seconds.
> 
> The IETF's standard end-to-end transport protocols have not been designed to
> minimize the extra delay introduced by them into the
> network. TCP, as a side effect of filling the buffer until it experiences
> drop-tail loss, effectively maximizes the delay. While this works well for
> applications that are not delay-sensitive, it harms interactive applications
> that share the same bottleneck. VoIP and games are particularly affected, but
> even web browsing may become problematic.
> 
> TANA is a transport-area WG that will focus on broadly applicable techniques
> that allow large amounts of data to be consistently transmitted without
> substantially affecting the delays experienced by other users and
> applications.
> 
> (1) An experimental 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.
> 
> * eliminate long standing queues and thus keep delay low when no other traffic
> is present,
> * operate well in today's typical networks with FIFO queueing with drop-tail
> discipline,
> * where available, use explicit congestion notification (ECN), active queue
> management (AQM), and/or end-to-end differentiated services (DiffServ).
> 
> Application of this algorithm to existing transport protocols (TCP, SCTP,
> DCCP) is expected to occur in the working groups that maintain those
> protocols.
> 
> (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.
> 
> Standard Internet congestion control result in different transport connections
> sharing bottleneck capacity. When an application uses several unchoked and not
> rate-limited transport connections to transfer through a bottleneck, it may
> obtain a larger fraction of the bottleneck than if it had used fewer
> connections. Although capacity is the most commonly considered bottleneck
> resource, middlebox state table entries are also an important resource for an
> end system communication. Other resource types may exist, and the guidelines
> are expected to comprehensively discuss them.
> 
> Applications use a variety of techniques to mitigate these concerns.  These
> techniques have not always been reviewed by the IETF and their interaction
> with TCP dynamics is poorly understood.  The WG document the known techniques,
> discussing the consequences and, where appropriate, provide guidance to
> application designers.
> 
> (3) The WG will discuss how to best take into account prior work in the area.
> The outcome will be either incorporated into the document specifying the
> experimental congestion control algorithm or into a separate document
> summarizing prior work.
> 
> 
> 
> Goals and Milestones
> 
> TBD  Submit "Multiple Transport Connections in Applications Design" to the
> IESG for consideration as an Informational RFC
> TBD  Submit "Transport for Advanced Networking Applications (TANA)" to the
> IESG for consideration as an Experimental RFC
> 
> 
> Internet-Drafts
> 
>   <http://feeds.feedburner.com/~r/shlang/~6/1>
>  
> 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Oct 2008 12:14:59 -0700

Re-sending due to some earlier errors.. Sorry about the multiple copies to some of you.  

> From: Nicholas Weaver [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2008 11:51 AM
> To: Narayanan, Vidya
> Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; [email-masked]; 
> [email-masked]; Eddy, Wesley M. (GRC-RCN0)[VZ]
> Subject: Re: [p2pi] [tana] [tsv-area] TANA proposed charter
> 
> 
> > I'll start by saying that I do like the charter and believe
> that it is
> > scoped correctly.
> >
> > the answer may simply be that TANA is not applicable and
> hence, should
> > not be used.  However, I do think there are more grades to this.
> 

I was not necessarily talking about the application models that exist today alone, but, was trying to see how future-proof this work can be.  But, world of warcraft is probably not the right example here :) 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Oct 2008 12:15:35 -0700

Speaking for TANA, I do think it is nicely scoped to a good problem.  I was bringing up some points to consider within the scope of the current charter - or, are you saying that the current charter is only meant to be scoped to file transfer applications?  

Vidya 

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2008 11:53 AM
> To: Narayanan, Vidya
> [email-masked]; Eddy, Wesley M. (GRC-RCN0)[VZ]; Bruce Davie
> > driven by video download applications such as YouTube.
> Thanks to http
> > being the common firewall transport mechanism, much of the
> video now
> > runs over TCP.  So, is it really as cut and dry as the bulk
> data P2P
> > traffic needing to yield to Internet traffic?  As long as
> it is about
> > some background file transfer, perhaps that philosophy will
> just work.  
> > But, if the P2P app is also a video app, the answer is
> probably more
> > complex.
> >
> > important issue.  But, it would be good to think about what
> grades we
> > may need to address here.
> >
> > Regards,
> > Vidya
> 
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 21 Oct 2008 16:13:41 -0400

I think that over all this is a decent charter and I support and hope  
to participate in this work. Some comments and nits follow.
(I, by the way, have no trouble with the proposed name.)

Regards
Marshall

On Oct 21, 2008, at 9:17 AM, Stanislav Shalunov wrote:

> following proposed charter, based on the BoF description, capture  
> what the community was interested in?
>
> Thanks,  -- Stas
>
>
>
> mechanism that should saturate the bottleneck, maintain low delay,  
> and yield to standard TCP.
>

Should this read "should saturate bottlenecks while retaining  
fairness" ?

> Applications that transmit large amounts of data for a long time  
> with congestion-limited TCP, but without ECN fill the buffer at the  
> head of

s/ECN/ECN, /

> applications upload over thin home uplinks: delays in these cases  
> can sometimes be of the order of seconds.
>
> and games are particularly affected, but even web browsing may  
> become problematic.
>
> transmitted without substantially affecting the delays experienced  
> by other users and applications.
>
> 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.
>
> * eliminate long standing queues and thus keep delay low when no  
> other traffic is present,
> * quickly yield to regular best-effort traffic that uses standard  
> TCP congestion control,
> active queue management (AQM), and/or end-to-end differentiated  
> services (DiffServ).
>

Are there FEC issues here ? I see possibly a couple :

- FEC may have fairness / congestion control issues in this context as  
it involves bandwidth usage that scales with the underlying  
application, and yet may be separately controlled. In general it is  
assumed that, say, a 30% FEC is "OK" if the underlying application  
uses congestion control, but if you are trying to saturate a  
bottleneck that may not be true if the FEC is added on top of the  
saturating flow.

- in a scavenger service it might be very useful to have a mechanism  
to distinguish between control and other critical data, which might
benefit from FEC, and the mass of the data, which might not need or  
warrant FEC. Some standardized means of signaling this might be useful.

> 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.
>
> transfer through a bottleneck, it may obtain a larger fraction of  
> the bottleneck than if it had used fewer connections.

The above wording is not clear to me.

Are you referring to TCP in the above sentence ? If so, be specific.

> Although capacity is the most commonly considered bottleneck  
> resource, middlebox state table entries are also an important  
> resource for an end system communication.
> Other resource types may exist, and the guidelines are expected to  
> comprehensively discuss them.
>
> concerns.  These techniques have not always been reviewed by the  
> IETF and their interaction with TCP dynamics is poorly understood.   
> The WG document the known techniques, discussing the consequences  
> and, where appropriate,

s/The WG document/The WG will document/

> provide guidance to application designers.
>
> TBD  Submit "Multiple Transport Connections in Applications Design"  
> to the IESG for consideration as an Informational RFC
> TBD  Submit "Transport for Advanced Networking Applications (TANA)"  
> to the IESG for consideration as an Experimental RFC
>
>
> Internet-Drafts
>

---

From: Ted Faber <[email-masked]>
Date: Tue, 21 Oct 2008 13:23:27 -0700

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

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 21 Oct 2008 13:26:46 -0700

Why not:

Scavenger Network Congestion Protocols?

Since this is the real description of what the group is trying to do  
is congestion control protocols for scavenger services.

---

From: Ted Faber <[email-masked]>
Date: Tue, 21 Oct 2008 13:31:40 -0700

> Scavenger Network Congestion Protocols?

My ears would prick up for that.

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 22 Oct 2008 02:46:51 +0200

Very well scoped charter and I think the discussion so far has shown that besides clarifications and a need for a better name the charter is right on target. I am all for TANA or whatever its name is going to be.

I think what is very important to remember in these discussions is that we talk about content that is served from the edge of the network, i.e. your typical P2P application. Access network asymetry in terms of upstream and downstream (e.g. DSL) is e.g. an important factor. P2P apps have been shown to fill up the upstream very efficiently. Tit-for-tat in BitTorrent will (to some degree) make sure the downstream will not significantly exceed the upstream bandwidth (Stansilav correct me if I am wrong). So the upstream is usually the thing we need to worry about in those settings as it is the limiting factor. Downloading something from YouTube is therefore very different in nature although it qualifies as bulk traffic. Overall I think "file-like" content distribution is the main application field as application developers probably do not want to bet their application's functioning on the access link characteristics of their customers if delay is an issue e.g. Even the earlier Warcraft example is still "file-like". We do not need to explicitly write this down but trying to achieve more complex things to make all sorts of potential applications "happy" would probably too ambitous.

	Rolf

> The medical data is point to point, not P2P.  A single TCP 
> flow works well, and by being on real network, shouldn't 
> experience the buffer issues present in home gateways, and by 
> being a single flow, doesn't have the 
> congestion-monopolization properties that P2P transfer programs have.
> 
> Warcraft is not using P2P for playing, rather it is using P2P 
> to save money in the data transfer of "patches", which 
> include large amounts of content (textures, models, etc) 
> (thus my rant on cost shifting).
> 
> Additionally, on the video apps, to my mind these are often 
> badly done, and badly done in a way that the transport layer 
> can do nothing about.
> 
> Take YouTube for example.  Its flash-based structure is not 
> suitable (deliberately so!) for significant offline viewing.  
> Yet its buffer strategy is "Fill-er-up completely", when many 
> viewers will not stick around to watch the whole thing: a 
> substantial waste although it does improve seek time.
> 
> (Comedy Central's, OTOH, has a maximum buffer of about 10 
> seconds, so "stop in the middle" doesn't waste bandwidth).
> 
> Yet all of these apps don't also properly recognize "I don't 
> have ENOUGH bandwidth to keep up with realtime", and so don't 
> (aren't capable of in flash?) of switching to a lower-bitrate 
> encoded source.
> 

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 22 Oct 2008 07:48:36 +0200

Hi

Even though I understand that it is better to focus on the charter than
in the name I too beleieve that TANA does not say much.

I believe that somewhere along the track and also in the charter the
term "less than best effort transmission" was/is mentioned
A possible name would then be 

LETBET (LEss Than Best Effort Transport)

That said... there are a whole bunch of WG names out there that at first
glance does not say anything about the group. 

The charter looks OK from my perspective.

/Ingemar

> [mailto:[email-masked]] On Behalf Of Ted Faber
> Sent: den 21 oktober 2008 18:51
> To: Eddy, Wesley M. (GRC-RCN0)[VZ]
> > 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

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Oct 2008 08:18:49 +0200

Hi,

I also find the charter good and like Ingemar's name proposal "LETBET (LEss Than Best Effort Transport)"

Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Welzl <[email-masked]>
Date: Wed, 22 Oct 2008 09:53:33 +0200

I agree 100%, about both - charter and LETBET (which is my
favorite name proposal)

Cheers,
Michael

On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote:
> Hi,
> 
> I also think the charter is very well scoped.
> 
> However I'd like to see the *multiple connections* work item elaborated 
> and explained a little bit more!
> 
> about the name proposal both "LETBET (LEss Than Best Effort Transport)" and
> "Scavenger Network Congestion Protocols" sound good proposal to me.
> 
> /sal
> 
> Michael Menth wrote:
> > Hi,
> >
> >>> From: [email-masked] [mailto:[email-masked]] 
> >>> On Behalf Of Ted Faber

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Oct 2008 01:28:43 -0700

I'm not sure I'm reading the semantics of "Less than Best Effort" like other
folks. 

'Best Effort' has a well-defined semantics in the scope of Diffserv,
including a code point of its own. Less than best effort seems we are
defining a code point for such applications. Are we? The charter talks about
'end-to-end Diffserv'.

End-to-end diffserv is a challenge on its own given ISP policies, etc.

If the link is not saturated, are such application also treated as 'less
than best effort' by still being DSCP marked and treated differently within
routers? 

I would like if possible to decouple the 'less than best effort', as in
diffserv, from the algorithm per se.

Besides, there are ISPs that are worried about the effect that P2P have on
other applications when the link is saturated, but otherwise they do not
care. P2P would be treated like best effort in non-saturated situations (a
more ECN type approach).

Thanks,

Reinaldo

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 22 Oct 2008 10:49:28 +0200

Please see inline.

> Behalf Of Reinaldo Penno
> Sent: Wednesday, October 22, 2008 5:29 PM
> To: Michael Welzl; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tana] [tsv-area] TANA proposed charter
> 
> I'm not sure I'm reading the semantics of "Less than Best 
> Effort" like other folks. 
> 
> 'Best Effort' has a well-defined semantics in the scope of 
> Diffserv, including a code point of its own. Less than best 
> effort seems we are defining a code point for such 
> applications. Are we? The charter talks about 'end-to-end Diffserv'.

I read this point in the charter differently. My interpretation is that if there is something available that helps you to achieve less-than-best-effort then please make use of it. TANA is not chartered to promote the global adoption of DiffServ for this purpose.

> If the link is not saturated, are such application also 
> treated as 'less than best effort' by still being DSCP marked 
> and treated differently within routers? 
> 
> I would like if possible to decouple the 'less than best 
> effort', as in diffserv, from the algorithm per se.
> 
> Besides, there are ISPs that are worried about the effect 
> that P2P have on other applications when the link is 
> saturated, but otherwise they do not care. P2P would be 
> treated like best effort in non-saturated situations (a more 
> ECN type approach).

That is exactly the point. P2P should not "harm" inelastic traffic. In order to do that, queues should not build up as a consequence of the P2P traffic. The charter according to my interpretation says that the most suitable of the set of available means should be used or any combination of it that makes sense.

> > I agree 100%, about both - charter and LETBET (which is my favorite 
> > name proposal)
> > 
> > Cheers,
> > Michael
> > 
> > 
> >> However I'd like to see the *multiple connections* work item 
> >> elaborated and explained a little bit more!
> >> 
> >> about the name proposal both "LETBET (LEss Than Best Effort 
> >> Transport)" and "Scavenger Network Congestion Protocols" 
> sound good proposal to me.
> >> 
> >> /sal
> >> 
> >> Michael Menth wrote:
> >>> Hi,
> >>> 
> >>> I also find the charter good and like Ingemar's name proposal 
> >>> "LETBET (LEss Than Best Effort Transport)"
> >>> 
> >>> Michael
> >>> 
> >>>> Even though I understand that it is better to focus on 
> the charter 
> >>>> than in the name I too beleieve that TANA does not say much.
> >>>> 
> >>>> I believe that somewhere along the track and also in the charter 
> >>>> the term "less than best effort transmission" was/is mentioned A 
> >>>> possible name would then be LETBET (LEss Than Best Effort 
> >>>> Transport)
> >>>> 
> >>>> That said... there are a whole bunch of WG names out 
> there that at 
> >>>> first glance does not say anything about the group.
> >>>>> I care about congestion control and nothing in the expansion of 
> >>>>> TANA indicated it was about congestion (to me).
> >>>>> 
> >>>>> --
> >>>>> Ted Faber

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Oct 2008 02:10:22 -0700

Hello,

Inline...

On 10/22/08 1:49 AM, "Rolf Winter" <[email-masked]> wrote:

> I read this point in the charter differently. My interpretation is that if
> there is something available that helps you to achieve less-than-best-effort
> then please make use of it. TANA is not chartered to promote the global
> adoption of DiffServ for this purpose.

Let me ask it differently. Is a deliverable of the algorithm to "desired
feaures...where available, use explicit congestion notification (ECN),
active queue management (AQM), and/or end-to-end differentiated services
(DiffServ)." ?

In other words, beside the immediate deliverable to provide an algorithm
that is delay bound, are we also going to specify how this new algorithm
"use" those other features?

It could go either way, I'm just looking for clarification on the scope of
the problem.

> That is exactly the point. P2P should not "harm" inelastic traffic. In order
> to do that, queues should not build up as a consequence of the P2P traffic.
> The charter according to my interpretation says that the most suitable of the
> set of available means should be used or any combination of it that makes
> sense.

Inelastic as is VoIP? In this case instead of making P2P as less than best
effort you can mark VoIP with EF. So, there is no need for "less than best
effort" in this case from a Diffserv perspective, only from a algorithmic
perspective.

Thanks,

Reinaldo

---

From: Roland Bless <[email-masked]>
Date: Wed, 22 Oct 2008 11:18:19 +0200

Hi Reinaldo,

> I'm not sure I'm reading the semantics of "Less than Best Effort" like other

Maybe RFC 3662 defines this more clearly.

> defining a code point for such applications. Are we? The charter talks about

See RFC 3662

> than best effort' by still being DSCP marked and treated differently within

Usually lower effort (LE) packets will go into a different queue
and served only if no other BE packets are waiting. So if
the BE queue is empty, LE packets will get the same treatment as BE
packets. Only in case of congestion, LE packets will be treated
differently.

> care. P2P would be treated like best effort in non-saturated situations (a

Yes, and that's exactly where LE helps: an ISP can be sure that
LE traffic will not harm other BE traffic at any time. In case
of congestion BE traffic will preempt LE traffic. If the
link is not saturated, LE will be treated like BE.

Regards,
 Roland

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Oct 2008 02:26:29 -0700

>> defining a code point for such applications. Are we? The charter talks about

Thanks Roland. I remember some of these discussions. Is there any effort to
make it standard, particularly the DSCP so the algorithm can use it?

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 22 Oct 2008 11:49:53 +0200

Inline.

> >> 
> >> I'm not sure I'm reading the semantics of "Less than Best Effort" 
> >> like other folks.
> >> 
> Diffserv, 
> >> defining a code point for such applications. Are we? The charter 
> >> talks about 'end-to-end Diffserv'.
> > 
> > I read this point in the charter differently. My interpretation is 
> > that if there is something available that helps you to achieve 
> > less-than-best-effort then please make use of it. TANA is not 
> > chartered to promote the global adoption of DiffServ for 
> this purpose.
> 
> Let me ask it differently. Is a deliverable of the algorithm 
> to "desired feaures...where available, use explicit 
> congestion notification (ECN), active queue management (AQM), 
> and/or end-to-end differentiated services (DiffServ)." ?
> 
> In other words, beside the immediate deliverable to provide 
> an algorithm that is delay bound, are we also going to 
> specify how this new algorithm "use" those other features?
> 

How such a feature could be used is very likely already documented to a sufficient level of detail elsewhere. See e.g. the RFC Roland quoted earlier. I personally think TANA should focus on what can be achieved in the absence of these features. From a charter perspective, it would be wrong to neglect the existence of these features though. So if somebody feels that there is a significant gap that leaves a number of questions open on how TANA could make use of an existing technique then I believe there is room in the WG for that. DiffServ I personally feel might not meet that criteria. But it is a very good point you raise and maybe the charter could be made more explicit in that respect.

> It could go either way, I'm just looking for clarification on 
> the scope of the problem.
> > 
> >> 
> >> If the link is not saturated, are such application also treated as 
> >> 'less than best effort' by still being DSCP marked and treated 
> >> differently within routers?
> >> 
> >> Besides, there are ISPs that are worried about the effect that P2P 
> >> have on other applications when the link is saturated, but 
> otherwise 
> >> they do not care. P2P would be treated like best effort in 
> >> non-saturated situations (a more ECN type approach).
> > 
> > That is exactly the point. P2P should not "harm" inelastic 
> traffic. In 
> > order to do that, queues should not build up as a 
> consequence of the P2P traffic.
> > The charter according to my interpretation says that the 
> most suitable 
> > of the set of available means should be used or any 
> combination of it 
> > that makes sense.
> 
> Inelastic as is VoIP? In this case instead of making P2P as 
> less than best effort you can mark VoIP with EF. So, there is 
> no need for "less than best effort" in this case from a 
> Diffserv perspective, only from a algorithmic perspective.

Yes, if DiffServ is availabe you could do all sorts of things.

---

From: Laird Popkin <[email-masked]>
Date: Tue, 21 Oct 2008 22:09:56 -0400 (EDT)

One technical point about p2p: a tit-for-tat mechanism only applies between downloaders (i.e. peers that have <100% of the data); seeds (i.e. peers with 100% of the data) send data without getting anything in return. This means that while the traffic between downloaders is balanced (so upstream is roughly equal to downstream, which would given asymmetrical consumer bandwidth would typically leave lots of available downlink capacity) it's entirely possible for many seeds to collectively saturate a downloader's downstream capacity. So while I agree that upstream is much more often the concern, we can't ignore downstream entirely.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Rolf Winter" <[email-masked]>
To: "Nicholas Weaver" <[email-masked]>, "Vidya Narayanan" <[email-masked]>
Cc: "TSV Area" <[email-masked]>, [email-masked], [email-masked], "Wesley M. Eddy (GRC-RCN0)[VZ]" <[email-masked]>
Sent: Tuesday, October 21, 2008 8:46:51 PM (GMT-0500) America/New_York
Subject: Re: [tana] [p2pi]   [tsv-area] TANA proposed charter

I think what is very important to remember in these discussions is that we talk about content that is served from the edge of the network, i.e. your typical P2P application. Access network asymetry in terms of upstream and downstream (e.g. DSL) is e.g. an important factor. P2P apps have been shown to fill up the upstream very efficiently. Tit-for-tat in BitTorrent will (to some degree) make sure the downstream will not significantly exceed the upstream bandwidth (Stansilav correct me if I am wrong). So the upstream is usually the thing we need to worry about in those settings as it is the limiting factor. Downloading something from YouTube is therefore very different in nature although it qualifies as bulk traffic. Overall I think "file-like" content distribution is the main application field as application developers probably do not want to bet their application's functioning on the access link characteristics of their customers if delay is an issue e.g. Even the earlier War
 craft example is still "file-like". We do not need to explicitly write this down but trying to achieve more complex things to make all sorts of potential applications "happy" would probably too ambitous.

	Rolf

---

From: Kurt Tutschku <[email-masked]>
Date: Wed, 22 Oct 2008 12:30:51 +0200

Dear honored colleagues,

I think "LETBET" is nice to remember, but is my opinion very dangerous.

The part of "BET" in the name recalls me some associations with  
auctions and bandwidth broker systems (see RFC 2638).

I think TANA should and will distinguish itself from previous work.  
Therefore, I would be in favor of another name.

Best Regards
Kurt

Am 22.10.2008 um 09:53 schrieb Michael Welzl:

>> Transport)" and
>>>> the
>>>>> TANA

---
Prof. Dr. Kurt Tutschku
Chair of Future Communication (Endowed by Telekom Austria)
Institute of Distributed and Multimedia Systems, Faculty of Computer  
Science
University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria.

Tel: +43/1/4277-39611

mailto:[email-masked] or mailto:[email-masked]

---

From: <[email-masked]>
Date: Wed, 22 Oct 2008 13:29:18 +0100

I agree that this is a pretty good charter. Just a few comments in-line
(mainly supporting Bruce's earlier comments).

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bruce Davie
> Sent: 21 October 2008 16:06

Agree. In fact even ECN fills the head of the queue if it runs on RED
algo...

> isolation in the queues, this increases..."

Agree

> "If the buffer size is one RTT, the delay doubles...."

Or "If the buffer is set to one RTT as often recommended, the delay
doubles..."

> standard TCP congestion control"

And do we mind about how it reacts to any other congestion control? Do
we need to mention possible interactions with other delay-based CC's?

> suggest deleting "today's typical"

Agree - not sure we can call anything typical and we don't want to limit
our scope too much.

> practices for applications in this regard."

More or less agree with Bruce but it would be nice to make it clearer
that we are talking about one or more connections: "(2) A document that
discusses the tradeoffs of using many concurrent transport connections
to one peer and/or to different peers compared to single transport
connections between peers and recommends best practices for applications
in this regard."

> the WG. I like all of Wesley's suggestions better, MILT probably being

Yes the name is awful, but as with all such things we are already
getting used to the acronym TANA. However if we do decide to change the
name how about:

"Congestion-Optimisation for Large Transfers (COLT)"
"Transport for Impact Limited Large Transfers (TILTT)"

Toby

> > mouth

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Oct 2008 05:45:48 -0700

On Oct 22, 2008, at 1:49 AM, Rolf Winter wrote:
> That is exactly the point. P2P should not "harm" inelastic traffic.  
> In order to do that, queues should not build up as a consequence of  
> the P2P traffic. The charter according to my interpretation says  
> that the most suitable of the set of available means should be used  
> or any combination of it that makes sense.

There are actually at least two sources of harm that BitTorrent and  
related bulk-data P2P protocols can cause:

A)  Self harm on access-link buffers:  Simply because the protocol  
will very easily saturate uplinks for residences, and devices ON the  
uplinks (NAT boxes, etc) are often criminally overbuffered.  This is  
not really affected by the multiple-TCP flow nature of the protocols  
in question, as a single TCP flow will happily grab the full buffer as  
well, but P2P protocols tend to be the heaviest user of the uplink.

B)  Congestion on shared-access uplinks:  DOCSIS is explicitly a  
shared-bandwidth media.  Thus a few users of a P2P protocol (many- 
flow, full-data-rate) can acquire a large amount of the shared channel.

Part of the problem:  A and B may require different strategies and  
solutions:

A is the one which the P2P developers are most interested in, because  
that directly harms their customers.  If you provide a solution to A,  
it will be deployed, and quickly.

B is the source of conflicts between the ISP and P2P, why ISPs have  
tried managing the upload rate, and why some ISPs, notably Comcast,  
are shifting to a network-enforced fairness approach.

Dealing with B is what I personally consider essential for a scavenger  
class protocol, and the more interesting problem, but I think it may  
be trickier, because you can solve A but not B with delay-based hacks.

But solving B also has another problem:  If P2P program Gamma and P2P  
program Delta are sharing the same uplink, and Gamma implements a  
scavenger protocol, its going to get squeezed out if congestion occurs  
on the uplink and, if any reciprocity is involved, the user's download  
is also going to suffer.

So there may be reasons for P2P developers to use techniques which  
solve A AND B, but there doesn't seem to be so clear an incentive for  
such solutions over solutions for A alone.

---

From: Roland Bless <[email-masked]>
Date: Wed, 22 Oct 2008 16:27:23 +0200

Hi Reinaldo,

> make it standard, particularly the DSCP so the algorithm can use it?

There was a decision in the DiffServ WG that Per Domain Behaviors
have to be Informational RFCs. There is a recommended codepoint
of using CSC 1 (see RFC 2474), i.e. 001000 as DSCP value
for the LE PDB.

Regards,
 Roland

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 22 Oct 2008 08:25:06 -0700

On Oct 22, 2008, at 2:18 AM, Roland Bless wrote:
>> have on

This is also roughly how Comcast is implementing fairness on their  
network:  Any user identified as being above a threshold of usage  
(averaged over ~15 minutes) is placed into a lower QoS category.  And  
as long as there is at least some capacity headroom left over, the  
heavy users aren't starved out, the light users don't notice, and the  
heavy users traffic just negotiates between itself.

However, this brings up a question:

Should a scavenger service be true LE, if the network does not support  
QoS?  In such a case, the service can't yield instantly anyway, so the  
question is what is the equilibrium it goes to relative to other flows.

Should it actually yield completely to other TCP flows on the network?

Or should it instead have some equilibrium position thats a stated  
fraction of what a normal TCP flow would achieve under the  
circumstances?

EG, a "Scavenger App" has N flows, on a congested link shared with a  
significant number of normal TCP flows.

Given x is the equilibrium transfer rate of a single TCP flow.

If the scavenger app's flows were normal TCP, the equilibrium point in  
congestion with others would be Nx

Should the goal be to have the equilibrium value be X?  (No matter the  
# of peers, the app behaves like a single TCP flow for equilibrium  
purposes)

Should the goal be to have the equilibrium be some fraction of X?  Zero?

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 22 Oct 2008 11:26:59 -0400

I am not sure that this is still a charter discussion, but...

On Oct 22, 2008, at 4:28 AM, Reinaldo Penno wrote:

> like other
> defining a code point for such applications. Are we?

I absolutely think that we should. This has been proposed before - RFC  
3662

Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use  
(EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]  
may be used as the PHB for the LE traffic aggregate. This document  
does not specify the exact DSCP to use inside a domain, but instead  
specifies the necessary properties of the PHB selected by the DSCP. If  
a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
...
The notion of having something "lower than Best Effort" was raised in  
the Diffserv Working Group, most notably by Roland Bless and Klaus  
Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for  
enterprise multimedia applications. One of its first applications was  
to re-mark packets within multicast groups [NRS]. Therefore, previous  
discussions centered on the creation of a new PHB. However, the  
original authors (Brian Carpenter and Kathleen Nichols) believe this  
is not required and this document was written to specifically explain  
how to get less than Best Effort without a new PHB.

> The charter talks about

> End-to-end diffserv is a challenge on its own given ISP policies, etc.

Much of which LTBE gets around. (It does not directly hurt LTBE  
traffic to turn it into
BE traffic, and it provides a benefit to the ISP to keep it LTBE,  
unlike the case for
priority "Better than best effort" diffserve codepoints, where you  
realistically need a contract with the
ISP to get them to prioritize it, and where it does potentially hurt  
the traffic to turn it into BE.)

I have talked to ISP representatives about this and they have been  
generally supportive both of the concept
and of honoring the LTBE tag (which, after all, gives them the green  
light to drop the traffic).

> 'less

I would regard that as an implementation detail. If LTBE translated  
into "do not queue this traffic"
(for a high level view of queuing - my understanding is that some  
queuing may be unavoidable
"under the hood" in some routers) then this traffic would be treated  
like best effort in non-saturated situations.

A "do not resuscitate" request has no actual effect as long as the  
patient does not need resuscitation. I would envision this as working  
similarly.

> care. P2P would be treated like best effort in non-saturated  

I think that in almost any scheme LTBE traffic would be treated like  
best effort in non-saturated situations.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 22 Oct 2008 11:32:52 -0400

On Oct 22, 2008, at 11:25 AM, Nicholas Weaver wrote:

> (averaged over ~15 minutes) is placed into a lower QoS category.   
> And as long as there is at least some capacity headroom left over,  
> the heavy users aren't starved out, the light users don't notice,  
> and the heavy users traffic just negotiates between itself.

> Should a scavenger service be true LE, if the network does not  
> support QoS?  In such a case, the service can't yield instantly  
> anyway, so the question is what is the equilibrium it goes to  
> relative to other flows.
>

If the network doesn't support QOS, how would it know ? If I am  
ignoring code points, how do I know what the
code point is ?

Regards
Marshall

> If the scavenger app's flows were normal TCP, the equilibrium point  
> in congestion with others would be Nx
>
> Should the goal be to have the equilibrium value be X?  (No matter  
> the # of peers, the app behaves like a single TCP flow for  
> equilibrium purposes)
>

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 22 Oct 2008 09:45:52 -0700

A refreshed working copy of the draft charter.  I've attempted to  
capture and reconcile the edits and clarify point (2).

We'll need to change the name, but it's not yet reflected because a  
new one hasn't been selected.

-- Stas

Chair(s):
TBD

Transport Area Advisor:

Mailing Lists:

Applications that transmit large amounts of data for a long time with  
congestion-limited TCP, but without AQM, fill the buffer at the head  
of the bottleneck link. With FIFO queue, this increases the delay  
experienced by other applications. With buffer of one RTT, the delay  
doubles. In some cases, the extra delay may be much larger. This is a  
particularly acute and common case is when P2P applications upload  
over thin home uplinks: delays in these cases can sometimes be of the  
order of seconds.

Desired features of such an algorithm are:
* saturate the bottleneck,
* eliminate long standing queues and thus keep delay low when no other  
traffic is present,
* quickly yield to traffic sharing the same bottleneck queue that uses  
standard TCP congestion control,
* add little to the queueing delays induced by TCP traffic,
* operate well in networks with FIFO queueing with drop-tail discipline,
* where available, use explicit congestion notification (ECN), active  
queue management (AQM), and/or end-to-end differentiated services  
(DiffServ).

(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 TCP connections to one destination and/or  
to different destinations.

Applications routinely open multiple TCP connections.  For example,  
P2P applications maintain connections to a number of different peers  
while web browsers perform concurrent downloads from the same web  
server.  Application designers pursue different goals when doing so:  
P2P apps need to maintain a well-connected mesh in the swarm while web  
browsers mainly use multiple connections to parallelize requests that  
involve application latency on the web server side.  The IETF  
transport area community is concerned about this practice, because  
standard Internet congestion control results in different transport  
connections sharing bottleneck capacity. When an application uses  
several non-rate-limited transport connections to transfer through a  
bottleneck, it may obtain a larger fraction of the bottleneck than if  
it had used fewer connections. Although capacity is the most commonly  
considered bottleneck resource, middlebox state table entries are also  
an important resource for an end system communication. Other resource  
types may exist, and the guidelines are expected to comprehensively  
discuss them.

Applications use a variety of techniques to mitigate these concerns.   
These techniques have not always been reviewed by the IETF and their  
interaction with TCP dynamics is poorly understood.  The WG will  
document the known techniques, discussing the consequences and, where  
appropriate, provide guidance to application designers.

Goals and Milestones

Internet-Drafts

No Requests for Comments

--
Stanislav Shalunov

---

From: Laird Popkin <[email-masked]>
Date: Wed, 22 Oct 2008 13:52:50 -0400 (EDT)

Nice job.

----- Original Message -----
From: "Stanislav Shalunov" <[email-masked]>
To: [email-masked], [email-masked], "[email-masked] Area" <[email-masked]>
Sent: Wednesday, October 22, 2008 12:45:52 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] [tana] TANA proposed charter

-- Stas

Chair(s):
TBD

Transport Area Advisor:

Mailing Lists:

Goals and Milestones

Internet-Drafts

No Requests for Comments

--
Stanislav Shalunov

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 22 Oct 2008 20:58:08 +0200

I like the charter, just one more fix.

> over thin home uplinks: delays in these cases can sometimes be of the

Last sentence should be: "A particularly acute and common case is when
P2P applications upload over thin home uplinks: delays in these cases
can sometimes be of the order of seconds."

-- 
Ciao,
Enrico

---

From: Mark Allman <[email-masked]>
Date: Wed, 22 Oct 2008 23:48:29 -0400

> Or at least until you bribe the NAT box vendors to implement some
 
That might in fact be something desirable from a user's point of view
and so the bribe might not be too big.  It's the general notion sketched
in this paper:

  Dan Ardelean, Ethan Blanton, Maxim Martynov. Remote Active Queue
  Management. Proceedings of the ACM SIGMM NOSSDAV 2008. May 2008.
  http://www.cs.purdue.edu/homes/eblanton/publications/raqm.ps

allman

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 23 Oct 2008 05:53:30 +0200

Nicholas,

I think in your Email below you are asking the right questions. That said, this is probably not about the charter any more but already doing the work (and this is very good as the new version of the charter looks fine - to me at least).

	Rolf

> Sent: Thursday, October 23, 2008 12:25 AM
> To: Roland Bless
> Cc: [email-masked]; [email-masked]; [email-masked]; Nicholas Weaver
> > Yes, and that's exactly where LE helps: an ISP can be sure that LE 
> > traffic will not harm other BE traffic at any time. In case of 
> > congestion BE traffic will preempt LE traffic. If the link is not 
> > saturated, LE will be treated like BE.
> 
> network:  Any user identified as being above a threshold of 
> usage (averaged over ~15 minutes) is placed into a lower QoS 
> category.  And as long as there is at least some capacity 
> headroom left over, the heavy users aren't starved out, the 
> light users don't notice, and the heavy users traffic just 
> negotiates between itself.
> 
> 
> Should a scavenger service be true LE, if the network does 
> not support QoS?  In such a case, the service can't yield 
> instantly anyway, so the question is what is the equilibrium 
> it goes to relative to other flows.
> 
> Or should it instead have some equilibrium position thats a 
> stated fraction of what a normal TCP flow would achieve under 
> the circumstances?
> 
> 
> EG, a "Scavenger App" has N flows, on a congested link shared 
> with a significant number of normal TCP flows.
> 
> If the scavenger app's flows were normal TCP, the equilibrium 
> point in congestion with others would be Nx
> 
> Should the goal be to have the equilibrium value be X?  (No 
> matter the # of peers, the app behaves like a single TCP flow 
> for equilibrium
> purposes)
>

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 10:57:13 +0100

This is looking pretty good to me. Couple of minor changes inline...

Toby

____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Stanislav Shalunov
> Sent: 22 October 2008 17:46
> To: [email-masked]; [email-masked]; [email-masked] Area

" With FIFO queue, this increases the delay experienced by other
applications. With buffer of one RTT, the delay doubles."

--> " With FIFO queues, this increases the delay experienced by other
applications. With buffers of the order of one RTT, the delay doubles."

> types may exist, and the guidelines are expected to comprehensively

It would be nice to add something about the fact that TCP strongly
favours long-running flows over shorter flows and that this further
exacerbates the problems of capacity sharing. Not sure if this should go
here or in the first work item?

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 11:41:21 +0100

LETBET doesn't seem to me quite right. It seems to imply the WG would
only work on a very limited subset of work from its charter.

Having said that I can't think off-hand of a name that does sum things
up. Was playing round with NASTY (network-aware scavenger transport) but
that has the same problem as the above. I would love to fit it to
something like YIELD or GIVEWAY that sums up the idea in its acronym.

Toby

Of
> Ingemar Johansson S
> Sent: 22 October 2008 06:49
> To: Ted Faber; Eddy, Wesley M. (GRC-RCN0)[VZ]
> Cc: [email-masked]; [email-masked]; TSV Area
> Subject: Re: [p2pi] [tsv-area] TANA proposed charter
> 
> Hi
>

---

From: Bryan Ford <[email-masked]>
Date: Thu, 23 Oct 2008 14:54:33 +0200

On Oct 23, 2008, at 12:41 PM, <[email-masked]> <[email-masked] 
 > wrote:

I personally liked the suggestion someone else made earlier of "BACK- 
OFF" - meaning "Background Congestion Kontrol of File Flows" or  
something like that, wasn't it...?  (Maybe we could come up with an  
alternate word for the second 'F' that doesn't make it sound so  
narrowly scoped.)

Bryan

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Oct 2008 14:53:41 +0100

Just a comment/question on the last point...

> This is looking pretty good to me. Couple of minor changes inline...
<snip>

> here or in the first work item?

I see what you are saying, but I am not sure this is the topic for this 
proposed WG. If we are working on LBE techniques, then I'd expect the 
new methods to be less aggressive that bulk TCP, which seems to be less 
than short-flows handling intense bursts of activity. Have I missed 
something?

BTW: It seems elsewhere in the TANA mail that people have said that the 
short flows in the particular exemplar apps. seem likely to be mainly 
low volume/rate control flows.

Gorry

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 14:52:42 +0100

Yes, that seems a much better name. Also really memorable which helps. I
think it can be traced back to Marshall Eubanks. As you say flow sounds
a bit limiting and so does file. On the other hand it bears its meaning
on its face so quibbles about what the FF stands for are probably just
distractions...

Toby 

> From: Bryan Ford [mailto:[email-masked]]
> Sent: 23 October 2008 13:55
> To: Moncaster,T,Toby,CXR9 R
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
[email-masked]
the

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Oct 2008 16:01:45 +0100

So, let me add a few things to this discussion, to make sure I 
understand what is being said.

 From what I saw at the BoF, there was strong consensus to proceed, and 
this still seems to be so.

The charter seems close to what we need. I'd prefer a title for the 
second work item that reflects the purpose of the RFC-to-be (see note 
below on the name of the group). I'd expect more RFCs to follow later, 
if this WG develops work in this space.

There were a few emails on using a DSCP for LBE service, and since I 
raised this at the BoF, I'd like to clarify a little of what I intended. 
I think the WG should look at the transport issues applied to the 
current Internet - In my opinion the work should not *require* router 
changes to enable ECN, implement new DS codepoints, etc. The work should 
stimulate a new type of transport that *should* in turn be able to use 
new mechanisms such as an LBE DS offering, or ECN-provided feedaback, 
Quick-Start, and a range of other mechanisms that may help in the 
future. I think this is what the proposed Charter says now...

I think the name of the BoF was OK, but the name doesn't reflect the 
role being sketched by the Charter. The charter is very 
Congestion-Control orientated, and rightly so in my opinion. A name that 
better reflects that would be good. We've had various suggestions... and 
I guess we need to "pick" one, of those I have seen, the most promising 
ones seem to be:

Scavenger Network Congestion Protocols
Background Congestion Control (BACKCC)
Background Congestion of File Flows (BACKOFF) - or similar.
Minimizing Impact of Large Transfers (MILT)
Congestion-Optimisation for Large Transfers (COLT)
Transport for Impact Limited Large Transfers (TILT)

Note: As I recall, an IETF WG can not have a hyphen or underscore in 
their name.

Best wishes,

Gorry

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 23 Oct 2008 11:24:49 -0700

I do like BACKOFF as well.  I think "File" captures what we are doing here quite well - it doesn't look like we are dealing with all kinds of large data - as I said in one of my earlier emails, video fits the large data bill, but, it doesn't look like we would consider that as part of this work.  

In fact, it would benefit to have the charter explicitly call out that this is meant for large data that can be modeled as file downloads or something to that effect. 

Vidya 

> Behalf Of [email-masked]
> Sent: Thursday, October 23, 2008 6:53 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Yes, that seems a much better name. Also really memorable 
> which helps. I think it can be traced back to Marshall 
> Eubanks. As you say flow sounds a bit limiting and so does 
> file. On the other hand it bears its meaning on its face so 
> quibbles about what the FF stands for are probably just 
> distractions...
> 
> Toby 
> 
> > On Oct 23, 2008, at 12:41 PM, <[email-masked]> 
> > <[email-masked]  > wrote:
> > > up. Was playing round with NASTY (network-aware scavenger 
> transport) 
> > > but that has the same problem as the above. I would love 
> to fit it 
> > > to something like YIELD or GIVEWAY that sums up the idea in its
> acronym.
> > 
> > > than
> > >> term "less than best effort transmission" was/is mentioned A 
> > >> possible name would then be
> > >>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 24 Oct 2008 13:31:38 -0400

Good charter so far.  Agree that we need a better name.  I intend to
participate as a document author, document contributor, and a reviewer.
 
Jason

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stanislav Shalunov
	Sent: Tuesday, October 21, 2008 9:17 AM
	To: [email-masked]; [email-masked]; TSV Area
	Subject: [p2pi] TANA proposed charter

	At the BoF in Dublin, we observed strong interest and consensus
that the TANA work should go forward as a working group.  Does the
following proposed charter, based on the BoF description, capture what
the community was interested in?

	Thanks,  -- Stas

	Chair(s):
	TBD

	Transport Area Advisor:
	
	Mailing Lists:

	
	The TANA WG is chartered to standardize a congestion control
mechanism that should saturate the bottleneck, maintain low delay, and
yield to standard TCP.
	
	Applications that transmit large amounts of data for a long time
with congestion-limited TCP, but without ECN fill the buffer at the head
of the bottleneck link. This increases the delay experienced by other
applications. In the best case, with an ideally sized buffer of one RTT,
the delay doubles. In some cases, the extra delay may be much larger.
This is a particularly acute and common case is when P2P applications
upload over thin home uplinks: delays in these cases can sometimes be of
the order of seconds.
	
	The IETF's standard end-to-end transport protocols have not been
designed to minimize the extra delay introduced by them into the
	network. TCP, as a side effect of filling the buffer until it
experiences drop-tail loss, effectively maximizes the delay. While this
works well for applications that are not delay-sensitive, it harms
interactive applications that share the same bottleneck. VoIP and games
are particularly affected, but even web browsing may become problematic.
	
	TANA is a transport-area WG that will focus on broadly
applicable techniques that allow large amounts of data to be
consistently transmitted without substantially affecting the delays
experienced by other users and applications.

	(1) An experimental 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.

	Application of this algorithm to existing transport protocols
(TCP, SCTP, DCCP) is expected to occur in the working groups that
maintain those protocols.
	
	(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.
	
	Standard Internet congestion control result in different
transport connections sharing bottleneck capacity. When an application
uses several unchoked and not rate-limited transport connections to
transfer through a bottleneck, it may obtain a larger fraction of the
bottleneck than if it had used fewer connections. Although capacity is
the most commonly considered bottleneck resource, middlebox state table
entries are also an important resource for an end system communication.
Other resource types may exist, and the guidelines are expected to
comprehensively discuss them.
	
	Applications use a variety of techniques to mitigate these
concerns.  These techniques have not always been reviewed by the IETF
and their interaction with TCP dynamics is poorly understood.  The WG
document the known techniques, discussing the consequences and, where
appropriate, provide guidance to application designers.
	
	(3) The WG will discuss how to best take into account prior work
in the area.  The outcome will be either incorporated into the document
specifying the experimental congestion control algorithm or into a
separate document summarizing prior work.

	Goals and Milestones

	Internet-Drafts
	
	Transport for Advanced Networking Applications (TANA) Problem
Statement
	
http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statemen
t-01.txt
	
	No Requests for Comments