Subject: Re: [Sipping] Draft agenda / No overload design team update?

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 2 Apr 2008 17:04:02 +0200

Dear Jonathan/Volker and all,

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?

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)

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:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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:[email-masked]]
> > 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: [email-masked] [mailto:[email-masked]] 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 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] 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 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [email-masked]
> 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 [email-masked] for questions on current 
> sip Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 3 Apr 2008 04:15:08 +0200

"goodput" and "call set-up delay (CSD)" are *different* performance
metrics!
CSD is related to the realtime response behaviour of a (SIP) node under
different *load* conditions.
"goodput" is related to throughput of a (SIP) node under different
*load* conditions.

Please distinguish *load* and *performance* related metrics.
Load relates to SIP session attempt rate, call request rate, or sth like
that.
The *offered load* then is such a request rate, weighted with the
*expected* service time(s) by the SIP node.

Goodput is then the portion of *successfully* served load (e.g. a
completed SIP session), and
badput is the portion of unsuccessfully processed load.

A goodput related performance metric is for instance the "SIP session
completion rate" (or whatever, you may replace "SIP session" by "call"
or "dialog" or ...).
A badput related performance metric is e.g. blocking rate, discard rate,
etc

Under *stationary* conditions holds following equation:
goodput = load - badput

-Albrecht

PS
"Overload control" is a correct term for all kind of load regulation
mechanisms in the "signalling plane" (control plane). Agreed, you may
find more terms when looking deeper in publications (like e.g. overload
protection etc). 

PSS
I don't know the origins of the terms goodput and badput, but I could
imagine that these terms are commercially driven (because goodput
traffic may be charged/billed, but not badput ... ).

> [mailto:[email-masked]] On Behalf Of Saverio Niccolini
> Sent: Mittwoch, 2. April 2008 17:04
> To: [email-masked]
> Cc: Rosario Garroppo
> I see that many mechanisms reach the theoretical bound and 
> the performance is referred to as "goodput"
> 
> 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)
> 
> 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 
> happens (this is what the mechanisms and the simulations 
> investigated in 
> 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
> 
> 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.
> > 
> 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:
> [mailto:[email-masked]] On
> > > Behalf
> > >> Of Gonzalo Camarillo
> > >> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: Volker Hilt <[email-masked]>
Date: Wed, 02 Apr 2008 22:59:05 -0400

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

> is set up but with a 20 sec can not be really considered goodput)
Yes. See above.

Volker

-- 
Volker Hilt                      Bell Labs / Alcatel-Lucent
phone: +1 732 888 7206           791 Holmdel-Keyport Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 4 Apr 2008 07:00:15 +0200

Dear volker,

would you please comment also on my second question?
I still think the terminology of "overload control" is quite
unclear.

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 "avoidance" and "control"

the former refers to avoiding a congestion 
situation from happening (this is what the mechanisms and
the simulations investigated in
http://www3.ietf.org/proceedings/08mar/slides/tsvarea-3.ppt

the latter refers to controlling such a situation once it happened 
(e.g., because a server went down, because something unexpected 
happened)

If I am right then I think we should be talking about
"overlad avoidance" instead of "overload control"

Comments are appreciated,
Saverio

> From: Volker Hilt [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 4:59 AM
> To: Saverio Niccolini
> Cc: [email-masked]; Rosario Garroppo
> > I see that many mechanisms reach the theoretical bound and the 
> > performance is referred to as "goodput"
> > 
> 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 
> 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 
> > the former refers to avoiding a congestion/overload 
> situation happens 
> > (this is what the mechanisms and the simulations investigated in 
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >   
> > 
> >> 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 
> >> resources in all nodes, some amount of which is needed even to 
> >> discard a request.
> algorithms do a 
> >> 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
> specific