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

From: "Das, Saumitra" <[email-masked]>
Date: Tue, 21 Oct 2008 14:49:26 -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"

>> Murari

>A successful algorithm here would not necessarily "lower than"

>best-effort, because the "low priority' flow could actually achieve higher throughput than a conventional TCP flow.

>I believe that the key phrase in the proposed charter is very much on target -- that the "TANA flows" rapidly yield to conventional TCP.

>It is possible to both rapidly yield *and* to rapidly claim bandwidth that conventional TCP algorithms would have left unused.

>The extent to which a given algorithm can rapidly claim bandwidth without imperiling existing TCP traffic is of course something that the WG would have >o review. But given the charter objective of "saturation" it is important to understand that this is not necessarily "low priority" traffic. It is >ndoubtedly very jitter-tolerant traffic that can be quite elastic in its bandwidth utilization for any short period of time.

>-----

>Caitlin Bestler

>[email-masked]<mailto:[email-masked]> - http://www.asomi.com/CaitlinBestlerResume.pdf

I think the term low priority refers to yielding to a conventional TCP flow and in those terms TANA flows are low priority.

The fact that they could claim unused and available bandwidth doesn't change the fact that they are lower priority than conventional TCP.

I agree with your point that this could in fact rapidly claim bandwidth faster than conventional TCP depending on the design but the priority consideration with relation to conventional TCP still remains.

I was wondering how different or aligned the goals of TANA are with something like TCP-LP which also yields to conventional TCP but uses the available

Unused bandwidth. Are we differentiating it based on the fact that TANA would be more aggressive in reclaiming unused bandwidth to the point of being

higher throughput than a conventional TCP flow? Or is TCP-LP one of the solution points for consideration.

Thanks

Saumitra

www.saumitra.info<http://www.saumitra.info>

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

---

From: "Robb Topolski" <[email-masked]>
Date: Fri, 24 Oct 2008 13:35:35 -0700

>
> ------------------------------
>
> 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)
>
>
Jason is speaking about me, here, and mistakenly so.  I'm not having fun
with the word scavenger.  My "axe" isn't that Comcast "wants" to starve
their heavy users, it is that it has picked an inappropriate method that
makes such an outcome possible.

Personally, I think ISPs should hand out special cable modems to 24/7/365
P2P users and ask them to install 'em on their non-critical machines (such
as something used for P2P) -- anything going through such modem is tagged
for that lower-priority service flow. That would keep the
gaming/VOIP/surfing traffic out of that class appropriately and ISPs could
probably drop both the caps and the throttling.

I'm not against the Scavenger class. I'm against throwing all of a users'
traffic into it.

--Robb

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

>
> 21 - Latency Insensitive Control Specifications (LICS)
> 22 - Time Insensitive Data Transfer Enhancements(TIDE or TID-E)
>
> I think the best "differentiators" word that I've heard in this discussion
is the word "Background."  (I've heard the word "passive" used as well, and
I generally think that's on target.)  I'm generally not of fan of names that
identifies this treatment for P2P or for file transfers or for large
transfers, because those can have any priority and can be streaming and it
might turn out to be just as appropriate to transfer thousands of small
files this way.  I think the word "Congestion" can be dropped because it's
not like we're eliminating congestion here, we're just identifying what we
don't care about during congestion.  If there is no congestion, it all ought
to get through, right?  So with that in mind, and keeping in mind we're
going to have to identify a few different network scenarios -- something
like "Background Optimized Transfer Handling (BOTH)."

Robb Topolski

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