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

["Das, Saumitra" <[e-mail]>]

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

>[e-mail]<mailto:[e-mail]> - 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>

_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi