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

On 10/22/08 2:18 AM, "Roland Bless" <bless@tm.uka.de> wrote:

> Hi Reinaldo,
> 
> Reinaldo Penno wrote:
>> I'm not sure I'm reading the semantics of "Less than Best Effort" like other
>> folks. 
> 
> Maybe RFC 3662 defines this more clearly.
> 
>> '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'.
> 
> See RFC 3662

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?

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

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi