Re: [PMOL] [bmwg] FW: [Sipping] Draft agenda / No overload design teamupdate?

["Saverio Niccolini" <[e-mail]>]

Dear all,

I think there are many unclear points and I do not know what is the
best mailig list where to discuss this (I added PMOL but maybe the
cross posting become too big now...)

I think the bmwg draft (http://www3.tools.ietf.org/html/draft-poretsky-bmwg-sip-bench-meth-02)
does not really help in getting what the sense of "goodput" means in the
overload control simulation resutls presented by Volker.
Would you (Daryl) suggest such metric is: "Maximum Session Attempt Rate"?
Or whatelse?

Are we sure that the goodput Volker is referring to is not
the same metric as you (Daryl) describe in Session Establishment Rate (SER):
http://tools.ietf.org/html/draft-malas-performance-metrics-08#section-3.6

Actually, in my opinion, is none of both.
I understand that the "goodput" is a *load* metric but that Volker
and the design team simulated it with *performance* constraints, i.e.,
if call set up delay is high than a configurable treshold T then the
call is not considered in the goodput

--> which leads to the assumption that it is a kind of a mixed
metric...  

Other interesting sentence from Volker in his email is:
"T does not have a significant impact, as long as it is chosen
reasonably, since the buffer occupancy stays within a given
limit with overload control"

I hope someone can clarify, from my perspective:
-- either such metric must be included in the drafts (as I wrote I
do not see cuh a metric in any draft)
-- or the goodput should be adapted to show metrics that are 
described in the drafts

Am I missing something?

Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     [phone]
Fax:     [phone]
e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
============================================================
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 Scott Poretsky
> Sent: Thursday, April 03, 2008 11:02 PM
> To: Daryl Malas; [e-mail]
> Cc: [e-mail]
> Subject: Re: [bmwg] FW: [Sipping] Draft agenda / No overload 
> design teamupdate?
> 
> Thanks Daryl.  We will make sure this is considered in the 
> next revision.
> 
> Scott
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Daryl Malas
> Sent: Thursday, April 03, 2008 1:09 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [bmwg] FW: [Sipping] Draft agenda / No overload 
> design team update?
> 
> FYI...I believe there was a draft written in BMWG to help 
> clarify some of these single DUT performance metric terms.  I 
> am forwarding this thread to the BMWG mailing list for 
> additional review as necessary.  
> 
> --Daryl
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Volker Hilt
> Sent: Wednesday, April 02, 2008 8:59 PM
> To: Saverio Niccolini
> Cc: Rosario Garroppo; [e-mail]
> Subject: Re: [Sipping] Draft agenda / No overload design team update?
> 
> Saverio,
> > 
> > I have two questions regarding the overload topic:
> > 
> > 1- in the simulations results reported in 
> > http://www3.ietf.org/proceedings/08mar/slides/tsvarea-3.ppt
> > I see that many mechanisms reach the theoretical bound and the 
> > performance is referred to as "goodput"
> > 
> > What is the meaning of goodput here? Is the "call set up delay"
> > of the calls a parameter investigated in the simulations?
> > 
> It is the number of calls that were successfully set up, 
> i.e., for which an INVITE transaction could be successfully 
> completed. The call setup delay is considered in that a 
> request is abandoned if it could not be set up within 10 
> seconds. The number of seconds does not have a significant 
> impact, as long as it is chosen reasonably, since the buffer 
> occupancy stays within a given limit with overload control.
> 
> > I try to explain my question better:
> > is the 140 cps goodput all related to calls that achieve a 
> call setup 
> > delay which is acceptable for a real-time call? (e.g. a 
> call that is 
> > set up but with a 20 sec can not be really considered goodput)
> > 
> Yes. See above.
> 
> Volker
> 
> 
> 
> > 2- terminology problem
> > I have a problem with seeing the term overload "control" 
> used here, if
> 
> > you refer to the literature you will see terms like 
> > congestion/overload "avoidance" and "control"
> > 
> > the former refers to avoiding a congestion/overload 
> situation happens 
> > (this is what the mechanisms and the simulations investigated in 
> > http://www3.ietf.org/proceedings/08mar/slides/tsvarea-3.ppt
> > in my opinion)
> > the latter refers to controlling such a situation once it happened 
> > (e.g., because a server went down, because something unexpected
> > happened)
> > 
> > Can you please clarify and tell me why we are not using overload 
> > avoidance when referring to this work?
> > 
> > Thanks a lot in advance,
> > Saverio
> > 
> > ============================================================
> > Dr. Saverio Niccolini
> > Senior Researcher
> > NEC Laboratories Europe, Network Research Division	
> > Kurfuerstenanlage 36, D-69115 Heidelberg
> > Tel.     [phone]
> > Fax:     [phone]
> > e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
> > ============================================================
> > 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 Jonathan Rosenberg
> >> Sent: Friday, February 29, 2008 10:43 PM
> >> To: Mary Barnes
> >> Cc: sipping; Gonzalo Camarillo
> >> Subject: Re: [Sipping] Draft agenda / No overload design 
> team update?
> >>
> >> There has also been progress since last ietf.
> >>
> >> One of the main points of feedback from last ietf, was that all of 
> >> the proposed algorithms showed the overall goodput going 
> to zero. As 
> >> we dug into this, the real problem is the simulation 
> model; the model
> 
> >> assumes the senders never back off, and assumes that there 
> is finite 
> >> resources in all nodes, some amount of which is needed even to 
> >> discard a request.
> >> So, when you put those together, the simulation model means ALL 
> >> algorithms would have this property.
> >>
> >> SO we've adjusted the models to focus on server to server 
> first, and 
> >> see whether the algorithms can adjust the load between servers by 
> >> asking the previous hop to reduce its rate. We don't worry for now 
> >> about how the previous hop does that.
> >>
> >> Volker will be presenting results that show several 
> algorithms do a 
> >> pretty good job of coming close to the optimal goodput 
> curve. Another
> 
> >> result in the slides is that rate-based feedback, where the 
> >> downstream node tells the upstream to slow down to a 
> specific rate, 
> >> works better than 'bang-bang' algorithms which use the Retry-After 
> >> field in a
> >> 503 to tell the upstream neighbor to stop completely for a 
> specific 
> >> amount of time. So, though we are not ruling such 
> algorithms out yet,
> 
> >> our focus will be on driving additional simulation cases 
> around the 
> >> rate-based mechanisms, all of which perform pretty 
> similarly based on
> 
> >> current simulations.
> >>
> >> Thanks,
> >> Jonathan R.
> >>
> >> Mary Barnes wrote:
> >>> Thank you for asking, as I wanted to highlight that Volker
> >> Hilt will
> >>> be presenting on behalf of the Overload Design team at the ICCRG 
> >>> meeting next week.  Related to that presentation, Lars Eggert 
> >>> (Transport AD) has given agenda time in the Transport Open Area 
> >>> meeting for Volker to provide a summary of that presentation:
> >>> http://www.ietf.org/proceedings/08mar/agenda/tsvarea.txt
> >>>
> >>> Note that this does conflict with XCON (and folks in SIMPLE
> >> will have
> >>> to run to catch the presentation as the TSVAREA slot
> >> overlaps the 10
> >>> minute break), but this is likely that best that could have
> >> been done
> >>> given the difficulty in scheduling RAI sessions in general.
> >>>
> >>> As folks might recall, the primary feedback at IETF-70 on
> >> the Overload
> >>> presentation was that we needed to involve the congestion control 
> >>> experts in the Transport area to get their input in this area, so 
> >>> that's why this topic is being discussed there this time around.
> >>>
> >>> Regards,
> >>> Mary. 
> >>>
> >>> -----Original Message-----
> >>> From: Asveren, Tolga [mailto:[e-mail]]
> >>> Sent: Friday, February 29, 2008 9:40 AM
> >>> To: Gonzalo Camarillo; sipping
> >>> Cc: Barnes, Mary (RICH2:AR00)
> >>> Subject: Draft agenda / No overload design team update?
> >>>
> >>> Noticed the absence of an update from overload design team,
> >> and am now
> >>> wondering whether there is any new data ready to be shared
> >> with the WG.
> >>> Maybe some non-WG meeting to inform the curious crowd?
> >>>
> >>> Thanks,
> >>> Tolga
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail] 
> [mailto:[e-mail]] On
> >>> Behalf
> >>>> Of Gonzalo Camarillo
> >>>> Sent: Friday, February 29, 2008 7:02 AM
> >>>> To: sipping
> >>>> Cc: Mary Barnes
> >>>> Subject: [Sipping] Draft agenda
> >>>>
> >>>> Folks,
> >>>>
> >>>> as you probably know, you can find the draft agenda for
> >> the SIPPING
> >>>> sessions at:
> >>>>
> >>>> http://www.ietf.org/proceedings/08mar/agenda/sipping.htm
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Gonzalo
> >>>>
> >>>> _______________________________________________
> >>>> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> >>>> This list is for NEW development of the application of SIP Use 
> >>>> [e-mail] for questions on 
> current sip Use 
> >>>> [e-mail] for new developments of core SIP
> >>> _______________________________________________
> >>> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> >>> This list is for NEW development of the application of SIP Use 
> >>> [e-mail] for questions on current sip Use 
> >>> [e-mail] for new developments of core SIP
> >>>
> >> -- 
> >> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> >> Cisco Fellow                                   Edison, NJ 08837
> >> Cisco, Voice Technology Group
> >> [e-mail]
> >> http://www.jdrosen.net                         PHONE: 
> [phone]
> >> http://www.cisco.com
> >> _______________________________________________
> >> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [e-mail] for questions on current sip Use 
> >> [e-mail] for new developments of core SIP
> >>
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [e-mail] for questions on current sip Use 
> > [e-mail] for new developments of core SIP
> 
> 
> -- 
> Volker Hilt                      Bell Labs / Alcatel-Lucent
> phone: [phone]           791 Holmdel-Keyport Rd
> email: [e-mail]     Holmdel, NJ 07733
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use [e-mail] for questions on current 
> sip Use [e-mail] for new developments of core SIP 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
> 
_______________________________________________
PMOL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pmol