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

[Marshall Eubanks <[e-mail]>]

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

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

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

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

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

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

>

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

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


>
>
> Thanks,
>
> Reinaldo
>
>

Regards
Marshall


> 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:tsv-area- 
>>>>>> [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