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

From: "Daryl Malas" <[email-masked]>
Date: Thu, 3 Apr 2008 11:09:22 -0600

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Volker Hilt
Sent: Wednesday, April 02, 2008 8:59 PM
To: Saverio Niccolini
Cc: Rosario Garroppo; [email-masked]
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:  [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

-- 
Volker Hilt                      Bell Labs / Alcatel-Lucent
phone: +1 732 888 7206           791 Holmdel-Keyport Rd
email: [email-masked]     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
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

---

From: "Scott Poretsky" <[email-masked]>
Date: Thu, 3 Apr 2008 17:02:15 -0400

Thanks Daryl.  We will make sure this is considered in the next
revision.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Daryl Malas
Sent: Thursday, April 03, 2008 1:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: [bmwg] FW: [Sipping] Draft agenda / No overload design team
update?

--Daryl

-----Original Message-----

Saverio,

Yes. See above.

Volker

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 4 Apr 2008 06:53:31 +0200

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott Poretsky
> Sent: Thursday, April 03, 2008 11:02 PM
> To: Daryl Malas; [email-masked]
> Cc: [email-masked]
> 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
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Daryl Malas
> 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
> 
> [mailto:[email-masked]] On Behalf Of Volker Hilt
> 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 
> [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
> 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