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

["Rolf Winter" <[e-mail]>]

Inline.

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

How such a feature could be used is very likely already documented to a sufficient level of detail elsewhere. See e.g. the RFC Roland quoted earlier. I personally think TANA should focus on what can be achieved in the absence of these features. From a charter perspective, it would be wrong to neglect the existence of these features though. So if somebody feels that there is a significant gap that leaves a number of questions open on how TANA could make use of an existing technique then I believe there is room in the WG for that. DiffServ I personally feel might not meet that criteria. But it is a very good point you raise and maybe the charter could be made more explicit in that respect.

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

Yes, if DiffServ is availabe you could do all sorts of things.

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


NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi