[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PMOL] [bmwg] FW: [Sipping] Draft agenda / No overload design teamupdate?
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. +49 (0)6221 4342-118
Fax: +49 (0)6221 4342-155
e-mail: saverio.niccolini at nw.neclab.eu <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014
> -----Original Message-----
> From: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On
> Behalf Of Scott Poretsky
> Sent: Thursday, April 03, 2008 11:02 PM
> To: Daryl Malas; sipping at ietf.org
> Cc: bmwg at ietf.org
> 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: bmwg-bounces at ietf.org [mailto:bmwg-bounces at ietf.org] On
> Behalf Of Daryl Malas
> Sent: Thursday, April 03, 2008 1:09 PM
> To: sipping at ietf.org
> Cc: bmwg at ietf.org
> 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: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] On Behalf Of Volker Hilt
> Sent: Wednesday, April 02, 2008 8:59 PM
> To: Saverio Niccolini
> Cc: Rosario Garroppo; sipping at ietf.org
> 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. +49 (0)6221 4342-118
> > Fax: +49 (0)6221 4342-155
> > e-mail: saverio.niccolini at nw.neclab.eu <-- !!! NEW ADDRESS !!!
> > ============================================================
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road,
> > London W3 6BL Registered in England 2832014
> >
> >
> >
> >> -----Original Message-----
> >> From: sipping-bounces at ietf.org
> >> [mailto:sipping-bounces at ietf.org] 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:tasveren at sonusnet.com]
> >>> 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: sipping-bounces at ietf.org
> [mailto:sipping-bounces at ietf.org] 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
> >>>> sip-implementors at cs.columbia.edu for questions on
> current sip Use
> >>>> sip at ietf.org 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
> >>> sip-implementors at cs.columbia.edu for questions on current sip Use
> >>> sip at ietf.org for new developments of core SIP
> >>>
> >> --
> >> Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
> >> Cisco Fellow Edison, NJ 08837
> >> Cisco, Voice Technology Group
> >> jdrosen at cisco.com
> >> http://www.jdrosen.net PHONE:
> (408) 902-3084
> >> 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
> >> sip-implementors at cs.columbia.edu for questions on current sip Use
> >> sip at ietf.org 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
> > sip-implementors at cs.columbia.edu for questions on current sip Use
> > sip at ietf.org for new developments of core SIP
>
>
> --
> Volker Hilt Bell Labs / Alcatel-Lucent
> phone: +1 732 888 7206 791 Holmdel-Keyport Rd
> email: volkerh at bell-labs.com 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 sip-implementors at cs.columbia.edu for questions on current
> sip Use sip at ietf.org for new developments of core SIP
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
> _______________________________________________
> bmwg mailing list
> bmwg at ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg
>
_______________________________________________
PMOL mailing list
PMOL at ietf.org
https://www.ietf.org/mailman/listinfo/pmol