Subject: [tana] 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

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

---

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...
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

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

---

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: 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: 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: 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
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

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
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

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: 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: 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: 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: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Oct 2008 12:03:08 -0700

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

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:07:19 -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]; [email-masked]; Eddy, Wesley M. (GRC-RCN0)[VZ]; 
> Bruce Davie
> 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
> 
> > 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: 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.  

> Cc: Nicholas Weaver; Stanislav Shalunov; TSV Area; [email-masked]; 
> [email-masked]; Eddy, Wesley M. (GRC-RCN0)[VZ]

Vidya

---

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

Vidya 

> [email-masked]; Eddy, Wesley M. (GRC-RCN0)[VZ]; Bruce Davie

---

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

> 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 
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

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: "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: Salvatore Loreto <[email-masked]>
Date: Wed, 22 Oct 2008 10:10:32 +0300

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:
>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of Ted Faber

---

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

---

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: 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: "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: 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: <[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: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Oct 2008 08:09:10 -0700

On Oct 24, 2008, at 7:52 AM, John Leslie wrote:
>
>   By the nature of a packet-forwarding internet, there will be delays
> due to queues filling. Thus marking packets as eligible for dropping
> as queues fill is a fundamental tool for controlling delay.
>
>   In the particular cases that are driving this work, a majority of
> end-systems involved will have uplink bandwidth configured to be less
> than downlink bandwidth. Thus, uplink queues may tend to fill first;
> and packet marking for the benefit of the first uplink router would
> have an obvious payback...

However, much of the problem arrises from the first uplink router, the  
one in the home, being horribly, HORRIBLY engineered.

A simple test:  A Linksys WRT64GL with the Linksys default firmware is  
my access router, connected to a generic DSL modem.

I have a sustained ping to a remote system at ICSI, 30ms away.

I start a full rate, SINGLE TCP flow to this remote system.  The ping  
time jumps up to 3 seconds!  Yes, the stupid NAT box or DSL modem (not  
sure which at this moment) has a 3 second packet buffer, and simple  
FIFO behavior.  Any full rate upload and I can kiss my connection  
goodbye.  Period.  End of story.  Have a nice day.

Remember, there are two problems that a scavenger class service must  
accommodate: the criminally overbuffered home access devices and  
common congestion in the ISP's uplink.

Packet marking may work great for the ISP's uplink, but I feel we must  
consider the access link devices to be stupid: Overbuffered, and with  
no support for any advanced queuing operation, ECN, DiffServe, or  
anything else, thus any scavenger class protocol can't rely on support  
for advanced traffic management features.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Oct 2008 10:24:49 -0700

On Oct 24, 2008, at 9:12 AM, John Leslie wrote:
>   Fortunately, the Linksys _could_ be easily programmed to fix that --
> and if the problem becomes obvious enough to enough buyers, the
> competition will fix it...

I disagree.

I've had DSL or cable modem connectivity for damn-near a decade now.   
And fixing it is easy: the data rates are trivial, the devices are  
often programmable, and the solution straightforward: just have only  
30ms of packet buffer, not 3s.  Yet these devices STILL have this  
problem.

And the only reason that as a clued user it would be fixable if its  
the Linksys box is I DELIBERATELY purchased the version where I can  
replace the firmware to fix something the vendors refused to fix for  
themselves.  And I just unplugged the linksys: its the DSL modem,  
purchased within the past 2.5 years.

(The reason its not a problem for me is I don't use P2P apps, and only  
rarely upload large quantities of photos)

So I think the conclusion should be there has been a market failure in  
this area, and that absent a miracle, this problem will remain.

---

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

---

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

> >> congestion-limited TCP, but without ECN fill the buffer at 
> the head 
> >> of the bottleneck link.

I believe I agree with that: ECN or AQM

JL

---

From: Laird Popkin <[email-masked]>
Date: Fri, 24 Oct 2008 13:35:23 -0400 (EDT)

My understanding from talking with some vendors of home routers is that if there were a standard for proper behavior in this area, they would be happy to conform to it. But if there's not a standard, it's hard for them to get engineers and sub-vendors to implement "be smart".

----- Original Message -----
From: "Nicholas Weaver" <[email-masked]>
To: "John Leslie" <[email-masked]>
Cc: [email-masked], [email-masked], "Nicholas Weaver" <[email-masked]>
Sent: Friday, October 24, 2008 1:24:49 PM (GMT-0500) America/New_York
Subject: Re: [p2pi] TANA proposed charter -- packet marking question

I disagree.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 24 Oct 2008 13:42:14 -0400

I suspect that cable modems and DSL modems have been over-buffered in
the upstream direction for many years, and it will take many years to
purge the old modems out of the installed base. So I believe it is
important for 'TANA' transport to work in that environment.

However, there may be an opportunity to point future modem developers in
the correct direction, e.g. correct buffering, AQM and ECN. It would be
helpful if the 'TANA' transport could take advantage of that support in
the future.

> just have only 30ms of packet buffer, not 3s

I've heard from other experts that 100ms or so of packet buffer makes
sense. I think we can agree that 1-3 seconds does not make sense.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Friday, October 24, 2008 1:25 PM
To: John Leslie
Cc: [email-masked]; [email-masked]; Nicholas Weaver
Subject: Re: [tana] [p2pi] TANA proposed charter -- packet marking
question

I disagree.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Oct 2008 11:13:26 -0700

(note: Pruned to just TANA.)

> sense. I think we can agree that 1-3 seconds does not make sense.

IIRC, The classic rule of thumb is ~RTT, so if you assume a 100ms RTT,  
you get 100ms of buffer.  Nick McKeown argues that it should really be  
RTT/sqrt(N) with N being the number of full-rate flows.  But I'm not  
an expert.

But again, IIRC this is to optimize TCP throughput: overbuffered  
doesn't improve throughput, and underbuffered means the TCP flow is  
not able to fully saturate the link.

But go less and you under-throughput but improve response time for  
other flows and jitter.  Since jitter is probably as important when  
dealing with competing flows (eg, real time games, voip: items which  
latency matters alot, and even short-flow web-surfing), there is an  
argument at least to be made that in the absence of better queue  
managment, far better to undersize than oversize.

(Again, I'm not an expert and could easily be wrong here).

And, admittedly, I'm biased for 30ms, because my latencies I care  
about for high-performance TCP uploads are to work, which is 30ms  
away.  :)

It does bring up that there needs to be a simple good set of "Best  
practices for Access Link Buffers" document/study to hand to vendors.   
And there seems to be degrees:

a)  Just cut the buffer to something reasonable.  (Which needs to be  
defined, but should probably be ~100ms or less.).

b)  Implement some form of active queue management:  Probably  
something simple would work well, esp since the number of flows  
involved is low and the data rates are trivial.

c)  Use ECN.

---

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

Re: "Scavenger Network Congestion Protocols" -- good, but the inclusion
of "congestion" could cause various congestion-deniers to avoid the
group.  ;-)  In such a case, perhaps "control" instead?  

I am also concerned at the use of "scavenger."  Despite the fact that we
all know what it means, certain folks with various axes prepared for the
grinding are already having fun demonizing the work scavenger, by saying
anyone that does this kind of thing just wants to starve their users and
let them scavenge for scraps of food, etc. (Layer 8 concern)

Anyway, I have observed these names, and am inserting some suggestions
of my own:

1 - Scavenger Network Control Protocols (SNCP or SCAV)
2 - Scavenger Network Congestion Protocols (SNCP or SCAV)
3 - Scavenger Network Control Mechanisms (SNCM or SCAV)
4 - Scavenger Network Congestion Mechanisms (SNCM or SCAV)
5 - Minimizing the Impact of Large Transfers (MILT)
6 - Concurrent Realtime And Bulk Applications (CRABA) 
7 - Fast Transfers Adding Minimal Latency (FTAML) 
8 - Background Transfer Optimizations Mechanisms (BTOM)
9 - Bulk And Realtime Flows Interacting as Good Neighbors (BARFIGN) 
10 - TCP Flow Interaction Fairness (TFIF)
11 - Background Congestion Control (BACK-CC)
12 - Background Congestion Control of File Flows (BACK-OFF)
13 - LEss Than Best Effort Transport (LETBET)
14 - Congestion-Optimisation for Large Transfers (COLT)
15 - Network Optimization for Large Transfers (NOLT)
16 - Control and Optimization for Large Transfers (COLT) 
17 - Transport for Impact Limited Large Transfers (TILT)
18 - Network-Aware Scavenger Transport (NAS-T or NASTY)
19 - Tragedy of the Commons Avoidance Techniques (TCAT)  ;-)
20 - Neighbor-friendly Large Transfer Optimization (NLTO)
21 - Latency Insensitive Control Specifications (LICS)
22 - Time Insensitive Data Transfer Enhancements(TIDE or TID-E)

Jason

> Sent: Tuesday, October 21, 2008 4:27 PM
> To: Ted Faber
> Eddy,Wesley M. (GRC-RCN0)[VZ]
> Since this is the real description of what the group is 
> trying to do is congestion control protocols for scavenger services.
> 
> 
> 
> > If you want people who are interested in congestion control to take 
> > part in your group, "Techniques for Advanced Networking 
> Applications"
> > will do

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Oct 2008 10:52:18 -0400

Stanislav Shalunov <[email-masked]> wrote:
> 
> A refreshed working copy of the draft charter...
> 
 
   Nicely stated!

   However, I wonder how many of us are on the same page when it comes
to the question of packet marking.

   Some of us quite clearly see this as a question of _how_ to use
DiffServ; others of us see this as how to _avoid_ DiffServ.

   That is not necessarily a problem...

> minimizes interference with regular best-effort traffic.

   This language calls for something other than DiffServ, which is fine
by me -- DiffServ will not always be available.

>   queue management (AQM), and/or end-to-end differentiated services  

   ... which raises the question of _how_ to determine which of these
(ECN, AQM, DiffServ) are available...

   It occurs to me that for the uplink, the ISP will tend to have the
best information on which are available _and_ if several are available,
which would serve best. Thus, having the ISP provide such information
is something I wouldn't want to rule out.

   IMHO, the proposed charter is silent on that question, which is OK...

   But, this work is closely allied to the work in ALTO, which could
in principle collect such information and pass it (unevaluated) to the
p2p application. It's not instantly obvious whether the TANA and ALTO
charters allow for this, and I'd be happier if that were obvious enough
to prevent arguments after the WGs are formed.

--
John Leslie <[email-masked]>
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Oct 2008 12:12:46 -0400

> one in the home, being horribly, HORRIBLY engineered.

   I agree, there are some horrible examples.

> common congestion in the ISP's uplink.

   Agreed. (And there are a number of different flavors of congestion
in the uplink.)

> for advanced traffic management features.

   Agreed, we can't rely on it.

   But we shouldn't rule out optimizing the happy case where there's
full support for one or more of these through to the actual bandwidth
bottleneck. It's not actually all that hard to get there, for clueful
users...

---

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 24 Oct 2008 11:33:06 -0700

On Oct 24, 2008, at 8:09 AM, Nicholas Weaver wrote:
> NAT box or DSL modem (not sure which at this moment) has a 3 second  
> packet buffer, and simple FIFO behavior.

I'm willing to bet it's the DSL modem and that the actual buffer size  
is a binary-round number, likely 64kB.

The NAT box isn't naturally a bottleneck and the brand you have  
doesn't attempt to impose an artificial one.

By the way, buffer provisioning for slow links is a problem that's  
harder than the "one RTT worth divided by whatnot" rule makes it out  
to be.  If anyone who makes DSL/cable modems is listening, please  
don't just cut the buffer -- it may well do more harm than good.

--
Stanislav Shalunov

---

From: "Robb Topolski" <[email-masked]>
Date: Fri, 24 Oct 2008 12:52:40 -0700

> DiffServ; others of us see this as how to _avoid_ DiffServ.
It's not clear to me what exactly you are referring to here.  If DiffServ is
something to be avoided, then something is wrong.

I think the goal is something akin to "get the appropriate and desired next
hop behavior if the ISP supports it" and get the ISPs out of the business of
trying to guess.  If you're worried about someone trying to use this work to
game the system, then I think a quota on the exploited DSCPs could provide
the necessary disincentive.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 24 Oct 2008 13:25:29 -0700

On Oct 24, 2008, at 11:33 AM, Stanislav Shalunov wrote:

> I'm willing to bet it's the DSL modem and that the actual buffer  
> size is a binary-round number, likely 64kB.

Confirmed by subsequest testing.

Although I think its 128 kB:  Sustained transfer rate is >40 kB/s, and  
latency is ~3S.

And my ISP has its own problem, the downlink is also overbuffered, but  
more like 1s.

> don't just cut the buffer -- it may well do more harm than good.

You're right.  Point taken.

But some of these are just SO far off what they should be that they  
really do need to be cut, badly.

There is probably a good argument for 300ms, 100ms, and perhaps even  
30ms (under the "better underbuffered then overbuffered" argument),  
and tradeoffs between maintaining peak TCP performance and maintaining  
interactivity if there isn't active queue management.  This needs to  
be hashed out (TANA isn't the place, but it does need to be someplace.)

And there may be arguments that you want something different on DSL  
(which is point to point) or DOCSIS (mediated shared access).   Or  
even something adaptive.

But 1s and 3s are just so far out there for typical residential  
networks and do represent a big issue, as such buffers mean that a  
single full-rate TCP flow makes the network completely unusable for  
interactive tasks.

What is the right IETF working group that should address this issue,  
to provide better guidance to equipment makers?

---

From: Bruce Davie <[email-masked]>
Date: Fri, 24 Oct 2008 16:35:32 -0400

It's actually not that easy to get a router and an access device (DSL  
modem or cable modem) to do the right thing when they are in separate  
boxes separated by an Ethernet: the router knows how to do smart  
queuing but there's no queue on the Ethernet; the access device isn't  
smart enough to do, say, Diffserv in its queue facing the uplink. (My  
home configuration works pretty well, but is so far from a typical  
home configuration that it's not worth talking about.)

As was noted in the BoF in Dublin, getting well designed routers and  
access devices out into the world and properly configured, and getting  
all the end systems to use Diffserv marking is a solution that we're  
not likely to see soon. That is why the charter says that goals of the  

> active queue management (AQM), and/or end-to-end differentiated  

The first bullet says "deal with the world as it is"; the second says  
"deal with the world as you wish it were"

I think that is a very sensible approach.

Bruce

On Oct 24, 2008, at 1:35 PM, Laird Popkin wrote:

> My understanding from talking with some vendors of home routers is  
> that if there were a standard for proper behavior in this area, they  
> would be happy to conform to it. But if there's not a standard, it's  
> hard for them to get engineers and sub-vendors to implement "be  
> smart".
>
> Cc: [email-masked], [email-masked], "Nicholas Weaver" <[email-masked] 
> >

---

From: Roland Bless <[email-masked]>
Date: Sun, 26 Oct 2008 20:15:29 +0100

Hi Nicholas,

> one in the home, being horribly, HORRIBLY engineered.

Not all such boxes are horribly engineered.
I'm currently using an AVM Fritz!Box (Linux based) that has
built-in VoIP support and even uses different queues
for voice and other data packets to avoid QoS problems
in case of congestion. Furthermore, it allows
to mark voice packets, e.g., with an EF codepoint (configurable).

> accommodate: the criminally overbuffered home access devices and common
> congestion in the ISP's uplink.

> consider the access link devices to be stupid: Overbuffered, and with no
> support for any advanced queuing operation, ECN, DiffServe, or anything
> else, thus any scavenger class protocol can't rely on support for
> advanced traffic management features.

I would say that supporting lower effort is far easier (code point
classifier + one additional queue and simple priority queueing)
than supporting ECN that usually requires some active queueing
mechanisms plus an appropriate parameter setting...

Regards,
 Roland

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 28 Oct 2008 13:16:24 -0500

Stanislav Shalunov 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?

Yes; I support the WG-to-be.

Regarding names, let me throw my pun in the ring.  Since alto and tana
are, to a small extent, tied at the hip, and since one meaning of
alto in Spanish is to halt (or stop), the new name for tana could be:

STOP: Scavenger Transport for Optimized Performance

Ciao.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 30 Oct 2008 07:06:44 -0700

Folks,

I don't think we've seen any new name suggestions last few days.

I believe we should go with Fast Transfers Adding Minimal Latency  
(FTAML).  The best name is one that says what it is.  Of the ones we  
have, FTAML is the one that comes closest -- the WG really is about  
fast transfers that add only a minimal latency.

A person glancing through the agenda will know what the WG is about.

I don't expect it would have any negative connotations for anyone.  As  
a bonus, it is also the only name on our list that's going to be  
uniquely googlable.  (There are a few hits for it, but far fewer than  
for others, and not related to networking protocols.)

Let's go with that.

Thanks,  -- Stas

--
Stanislav Shalunov

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 07:42:55 -0700

Stanislav Shalunov wrote:
> have, FTAML is the one that comes closest -- the WG really is about fast
> transfers that add only a minimal latency.

Hi, all,

This title could imply that TANA would transfer files *faster* than
existing TCP. That is exactly the opposite of what I would have
expected, but I'm wondering if we all have the same expectations...

My current concern is that there appear to be three independent issues:

	1) keeping long flows from unfairly using resources

	2) keeping long flows from delaying other traffic

	3) allowing flows (of any length) to scavenge resources
	when they are not used by 'best-effort' traffic

OK, so 1 and 2 are related, but #3 is different. #1 and 2 apply to ALL
flows, whereas #3 seems to assume voluntary user tagging.

I have not seen a charter that clarifies exactly which of these is the
PRIMARY focus.

If such an updated charter exists, can someone post it?

(until that issue is resolved, it's premature to try to converge on a
title, IMO)

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 30 Oct 2008 08:05:36 -0700

> 	when they are not used by 'best-effort' traffic

Joe,

I don't think these are independent.

(2) essentially implies (1).  I can't see a way around.  To minimize  
extra delay, you need to react to it.  If you react to a signal that  
TCP ignores until it reaches a high threshold (buffer size), you will  
react first.

And (3) is just an efficiency constrain -- otherwise, one could say  
that always sending at 0 rate is a solution.

The length of the flow is not changing (2) and (3) -- it's just that  
long flows keep latencies high for longer, so it's more felt as a  
problem.  But the latency is going to reach the buffer size for flows  
starting from a size that's enough to send one picture -- hardly long.

-- Stas

--
Stanislav Shalunov

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 08:45:02 -0700

Stanislav Shalunov wrote:
> extra delay, you need to react to it.  If you react to a signal that TCP
> ignores until it reaches a high threshold (buffer size), you will react
> first.

Agreed that 2 implies 1, and that 3 implies 2 and 1.

That's why we could solve:
	1
	1 and 2
	1 and 2 and 3

We need to pick.

> And (3) is just an efficiency constrain -- otherwise, one could say that
> always sending at 0 rate is a solution.

"just" is the key point - it's important to understand who sees 2 and/or
3 as key parts of the charter, or "just" related issues.

However, note that there are many solutions to 1 and 2 that have nothing
to do with backgrounding - they could "just" define a fairness mechanism
that is tied more to flow length than RTT (as is the current effect).

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 30 Oct 2008 09:24:02 -0700

> That's why we could solve:

1 and 2 and 3.  The first sentence of the charter says "a congestion  
control mechanism that should saturate the bottleneck, maintain low  
delay, and yield to standard TCP".  These are differently phrased than  
your exact points, but close semantically.

> 3 as key parts of the charter, or "just" related issues.

(2) is what the whole story is about, for short flows as well as  
long.  It was discussed at length in Dublin.  It's a big deal and a  
real engineering problem for 100+M users -- uploading from a home  
connection using standard TCP congestion control makes the connection  
unusable for interactive applications (a.k.a "the Internet doesn't  
work").

(1) follows.  (3) must be specified, or the problem isn't well-formed.

--
Stanislav Shalunov

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 09:55:27 -0700

> your exact points, but close semantically.

Close enough. OK, then I would view this as:

	- a scavenger service that doesn't impact other traffic

> (2) is what the whole story is about, for short flows as well as long. 

Do you mean #2 or #3? I.e., are you concerned with:

	a) some flows from slowing down other flows
	b) background flows from slowing down other flows

If (b), then, #3 is the whole story, and everything else follows.

If #2 is the whole story, then #3 is getting lost.

> It was discussed at length in Dublin.  It's a big deal and a real
> engineering problem for 100+M users -- uploading from a home connection
> using standard TCP congestion control makes the connection unusable for
> interactive applications (a.k.a "the Internet doesn't work").

See, that's a good example of #2 that has NOTHING do do with #3. File
transfer isn't always a 'background' service.

> (1) follows.  (3) must be specified, or the problem isn't well-formed.

Sure it is. E.g., the above can be handled by diffserv, but scavenger
cannot.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 30 Oct 2008 13:47:46 -0400

On Oct 30, 2008, at 12:24 PM, Stanislav Shalunov wrote:
> connection using standard TCP congestion control makes the  
> connection unusable for interactive applications (a.k.a "the  
> Internet doesn't work").
>

I don't believe 2 must follow from 1:  EG, you could get #2 by using a  
delay-based congestion control, but there is nothing which says delay  
based will necessarily yield a small, large, or complete amount when  
compared with drop-based TCP congestion control.

I believe both 1 and 2 ARE essential, but solving 2 doesn't  
necessarily solve 1.

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 30 Oct 2008 11:55:03 -0700

On Oct 30, 2008, at 10:47 AM, Nicholas Weaver wrote:
> I don't believe 2 must follow from 1:  EG, you could get #2 by using  
> a delay-based congestion control, but there is nothing which says  
> delay based will necessarily yield a small, large, or complete  
> amount when compared with drop-based TCP congestion control.

Delay-based CC in general does not need to yield to loss-based.  But  
if the goal is to keep the extra delay low, then the algorithm must  
reduce the rate as the extra delay increases.  The reduction for a  
sustained high extra delay -- congestion at max, from the perspective  
of a delay-based algorithm -- must be to near-zero.  And if the extra  
delay is increasing because of queued packets from a loss-based CC,  
it's hard to call the behavior of reducing the rate anything but  
yielding.

--
Stanislav Shalunov

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Oct 2008 21:06:26 +0200

Hi,

FYI, during the informal telechat today, the IESG has agreed to start  
external review of the WG charter. You can find the charter text that  
will be sent out by the secretariat for feedback below. (Stas, thanks  
for incorporating the feedback from the list!) You'll see that we've  
attempted to improve the WG name, too: "Low Extra Delay Background  
Transport (LEDBAT) WG".

The wider IETF community now gets one week to comment, and the IESG  
will then decide whether or not to charter during the telechat next  
Thursday. Please participate during the charter discussion on the main  
IETF list.

Finally: I'm looking for additional candidates for a second co-chair.  
If you are interested and have the cycles, please drop me a private  
email that explains why you'd be a good choice. There is *no*  
requirement for having prior IETF chairing experience.

Lars

---

Low Extra Delay Background Transport (LEDBAT) WG
[Note: The LEDBAT WG stems from the TANA BoF held in Dublin.]

Chair(s):
* Stanislav Shalunov <[email-masked]>
* 2nd co-chair to be determined

Transport Area Advisor:

Mailing Lists:

General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/tana/
[Note: If chartered, mailing list will change to [email-masked].]

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

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.

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

     * 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

     * be deployable for popular applications that currently
       comprise noticeable fractions of Internet traffic

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

     Once experience is gained with this congestion control
     algorithm on the Internet, the WG will consider if it is
     appropriate to ask the IESG to advance the document as a
     Proposed Standard.

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

Oct 2009  Submit "Multiple Transport Connections in Applications Design"
           to the IESG for consideration as an Informational RFC

Oct 2009  Submit "Low Extra Delay Background Transport (LEDBAT)"
           to the IESG for consideration as an Experimental RFC

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 30 Oct 2008 18:29:31 -0400

> Agreed that 2 implies 1, and that 3 implies 2 and 1.

I am not sure that I see that. Suppose that the solution of 3 was some  
sort of "do not queue" mechanism, and that as a result worse than best  
effort traffic could be sent at a high rate, without affecting BE  
traffic in any way. (Such a
mechanism would not necessarily be a function of flow length, by the  
way.)

How does that mean that this WTBE traffic will follow anything like  
TCP fairness ? Is that even relevant ?

It also seems to me that TANA WTBE traffic could be _faster_ than TCP.  
To see this, recall the typical bursty packet traces you get with TCP.  
Let's idealize that and say that on some network there is a burst of  
traffic lasting 100 milliseconds that causes packet drops roughly  
every 3 seconds. This will damp down on TCP, and thus WTBE traffic  
might have a higher data rate than TCP, even without interfering with  
it at all. Further, if the WTBE had FEC imposed with (say) a 5 %  
redundancy overhead, then the WTBE goodput might also be higher than  
the the TCP goodput. Is this really a problem ?

To put it another way, # 1 requires a definition of fairness. If it is  
TCP fairness, I don't see it. If it is some other definition, what is  
it ? (I would be careful in overlaying the term "fair," by the way. If  
there is a new definition, it
should have a new label in my opinion.)

Regards
Marshall

> iEYEARECAAYFAkkJ1n4ACgkQE5f5cImnZrvMuQCeLz7ger8iTj5eFwTKI74FjUFV
> qq4AnRL03uQKlP3eCAhaHKzqQ7kBv6+M
> =Se3L

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 18:26:42 -0700

Marshall Eubanks wrote:
>> mechanism would not necessarily be a function of flow length, by the way.)

Good point, so let me rephrase.

IMO, this WG is about:
	FIRST) allowing flows (of any length) to scavenge resources
	when not used by 'best-effort' traffic

	SECOND) scavenging implies that scavenger flows (of any length)
	do not interfere with, delay, or consume resources from other
	non-scavenger flows.

If this is the point of the WG, then I would *really* like the charter
to state so. Discussions of reducing delays, increasing throughput, etc.
are all - IMO- peripheral to supporting these two requirements.

>> How does that mean that this WTBE traffic will follow anything like TCP
>> fairness ? Is that even relevant ?
> 

Yes - *in the absence of competing TCP traffic*. In the presence of TCP
traffic, scavenger flows should always do worse than TCP would have done
over the same path.

Joe

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 30 Oct 2008 22:15:04 -0400

Dear Joe;

I think we are close to agreement, but a couple of small things :

> 	do not interfere with, delay, or consume resources from other

s/do not/MUST NOT/

> to state so.

Agree.

> Discussions of reducing delays, increasing throughput, etc.

Let me try again : Is the design goal that the WTBE traffic not  
interfere with BE traffic, or
that the WTBE traffic be slower than the BE traffic ?

I would propose that it should be the first, agree that the first will  
generally imply the second, and argue that if
there are corner cases or conditions where the first is true but the  
second is not, that that is OK.

Regards
Marshall

.

> iEYEARECAAYFAkkKXtIACgkQE5f5cImnZrsenACg183UChPr4OargIZEaHey2xE3
> 8LIAoOhpuKiA80nTACukbvIlQ4jw1+Dn
> =bwB+

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 19:26:08 -0700

...
>     do not interfere with, delay, or consume resources from other

Sure. I didn't use requirements language, but agreed.

>> second is not, that that is OK.

Agreed. I would say that the first is required, the second is expected
in some (or most, depending on your viewpoint) cases.

Joe

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 31 Oct 2008 03:39:26 +0100

Hi,

> Let me try again : Is the design goal that the WTBE traffic 
> not interfere with BE traffic, or that the WTBE traffic be 
> slower than the BE traffic ?
> 
> I would propose that it should be the first, agree that the 
> first will generally imply the second, and argue that if 
> there are corner cases or conditions where the first is true 
> but the second is not, that that is OK.

I think the second one doesn't say anything really. Even if WTBE is slower it still can interfere. So you haven't really solved anything except making WTBE slow and therefore unattractive. As you say, there might be cases where WTBE is indeed faster but that is OK, maybe desirable.
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: "Robb Topolski" <[email-masked]>
Date: Thu, 30 Oct 2008 21:33:06 -0700

On Thu, Oct 30, 2008 at 6:26 PM, Joe Touch <[email-masked]> wrote:

> so let me rephrase.
So far, the above text is the closest to what I'm expecting.

I'm not sure where to put this other thought, but the use of this class MUST
be end-point controllable or end-point requested, consistent with other
traffic treatment instructions on the Internet.  It is not appropriate for
some transit or access provider enroute just to dump whatever traffic they
want to into here.  They can offer incentives for its use through
discounting, lifting restrictions, or whatever.  I'd hate to find myself
trying to make VOIP calls or stream live video only to find that someone
along the route decided that they were going to throw my traffic overboard.

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Oct 2008 22:02:30 -0700

Robb Topolski wrote:
> 
> 
> On Thu, Oct 30, 2008 at 6:26 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     so let me rephrase.
> 
>     IMO, this WG is about:
> I'm not sure where to put this other thought, but the use of this class
> MUST be end-point controllable or end-point requested, consistent with
> other traffic treatment instructions on the Internet.  It is not
> appropriate for some transit or access provider enroute just to dump
> whatever traffic they want to into here.  They can offer incentives for
> its use through discounting, lifting restrictions, or whatever.  I'd
> hate to find myself trying to make VOIP calls or stream live video only
> to find that someone along the route decided that they were going to
> throw my traffic overboard.

Agreed. I used to refer to this as "user-tagged 'red' ATM", at least
back when ATM-NNI and UNI info was more prevalent.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 31 Oct 2008 13:00:49 +0200

On 2008-10-31, at 3:26, ext Joe Touch wrote:
> If this is the point of the WG,

I certainly believe both of these were the intent.

> then I would *really* like the charter

I certainly read the charter this way. But if there's ambiguous text,  
we do have a week to fix it, if folks send specific comments on the  
charter text. (Please refer to the latest "LEDBAT" charter.")

Thanks,
Lars