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

[Reinaldo Penno <[e-mail]>]

Hello,

Inline...


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

> Please see inline.
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
> 6BL | Registered in England 2832014
>   
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Reinaldo Penno
>> Sent: Wednesday, October 22, 2008 5:29 PM
>> To: Michael Welzl; [e-mail]; [e-mail]; [e-mail]
>> 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.

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.

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

> 
>> 
>> Thanks,
>> 
>> Reinaldo
>> 
>> 
>> On 10/22/08 12:53 AM, "Michael Welzl"
>> <[e-mail]> wrote:
>> 
>>> I agree 100%, about both - charter and LETBET (which is my favorite
>>> name proposal)
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> 
>>> On Wed, 2008-10-22 at 10:10 +0300, Salvatore Loreto wrote:
>>>> Hi,
>>>> 
>>>> I also think the charter is very well scoped.
>>>> 
>>>> However I'd like to see the *multiple connections* work item
>>>> elaborated and explained a little bit more!
>>>> 
>>>> about the name proposal both "LETBET (LEss Than Best Effort
>>>> Transport)" and "Scavenger Network Congestion Protocols"
>> sound good proposal to me.
>>>> 
>>>> /sal
>>>> 
>>>> Michael Menth wrote:
>>>>> Hi,
>>>>> 
>>>>> I also find the charter good and like Ingemar's name proposal
>>>>> "LETBET (LEss Than Best Effort Transport)"
>>>>> 
>>>>> Michael
>>>>> 
>>>>> Ingemar Johansson S wrote:
>>>>>> 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
>>>>>> 
>>>>>>  
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail]
>> [mailto:[e-mail]]
>>>>>>> On Behalf Of Ted Faber
>>>>>>> Sent: den 21 oktober 2008 18:51
>>>>>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]
>>>>>>> Cc: TSV Area; [e-mail]; [e-mail]
>>>>>>> Subject: Re: [tsv-area] TANA proposed charter
>>>>>>> 
>>>>>>> On Tue, Oct 21, 2008 at 09:12:10AM -0500, Eddy, Wesley M.
>>>>>>> (GRC-RCN0)[VZ] wrote:
>>>>>>>    
>>>>>>>> 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
>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/tana
>>>>>>   
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> tana mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tana
>>>> 
>>> 
>>> _______________________________________________
>>> tana mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tana
>> 
>> _______________________________________________
>> tana mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tana
>> 

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