Subject: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

From: Salvatore Loreto <[email-masked]>
Date: Tue, 5 Feb 2013 15:34:14 +0200

Dear WG partecipants,

Volker and I would like to initiate a second 2 weeks WG Last Call on
draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) 
Overload Control")
http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt

The first WGLC that we run ( 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have 
been discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *soc* mailing list 
([email-masked]),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.

The WG LC will end on Friday, February 19th.

Thank you,
Salvatore as an SoC co-chair.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 11 Feb 2013 09:34:44 +0200

this is just a reminder for this WG Last Call

I haven't seen yet any comment or feedback
please we really need you spend some time to reading and reviewing the draft

thanks a lot
Salvatore

On 2/5/13 3:34 PM, Salvatore Loreto wrote:
> draft-ietf-soc-overload-control-12 (" Session Initiation Protocol 
> (SIP) Overload Control")

---

From: <[email-masked]>
Date: Mon, 11 Feb 2013 08:59:17 +0000

I just have one comment:

Section 5.10.2 says that the response sent by a SIP server to non-participants clients in case of overload is a 503 without the Retry-After header. I did not find any text about the response sent by participating clients when they have to reject a request. I assume they should send a 503 without the Retry-After header as well. I would suggest adding the following sentence at the end of 5.10, after "it will need to reject these requests": In such cases, the SIP client shall reply to the requests with a 503 response without the Retry-After header.

BC

De : [email-masked] [mailto:[email-masked]] De la part de Salvatore Loreto
Envoyé : lundi 11 février 2013 08:35
À : [email-masked]
Cc : Volker Hilt
Objet : Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

thanks a lot
Salvatore

Volker and I would like to initiate a second 2 weeks WG Last Call on
draft-ietf-soc-overload-control-12 (" Session Initiation Protocol (SIP) Overload Control")
http://tools.ietf.org/id/draft-ietf-soc-overload-control-12.txt

The first WGLC that we run ( http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have been discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *soc* mailing list ([email-masked]<mailto:[email-masked]>),
or directly to the WG chairs (Murray Kucherawy and myself).

Thank you,

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Atle Monrad <[email-masked]>
Date: Fri, 15 Feb 2013 21:52:30 +0000

G'day

The draft is a 3GPP Rel-11 dependency that I support going forward.

I've read through the draft and have no real comments.

However, I find the statement in section 5.10.2 a bit odd

  .... It would be fair to devote the same amount
   of processing at the overloaded server to the combination of
   rejection and processing from a non-participating client as the
   overloaded server would devote to processing requests from a
   participating client.  This is to ensure that SIP clients that do not
   support this specification don't receive an unfair advantage over
   those that do.
Personally I would have used a term like "local policy" for such decisions and not the current guidance given in a the current "fair to devote" fashion ...

I'd like to see the draft progressing.

thanks
/atle

________________________________

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson

From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: Monday, February 11, 2013 2:35 AM
To: [email-masked]
Cc: Volker Hilt
Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

thanks a lot
Salvatore

Thank you,

---

From: "NOEL, ERIC (ERIC C)" <[email-masked]>
Date: Sun, 17 Feb 2013 17:49:06 -0500

Salvatore,

I read the document and have a few comments:

- Typos:
      + Section 5.4 page 12, second paragraph "... is larger than the value stored value, ...." --> "... is larger than the stored value, ..."
      + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for 0.5s" or "oc-validity=500"  --> "oc-validity=1000"

- Questions:
      + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to describe the client behavior upon receiving a response with the oc parameters filled in. This is in contrast with section 5.5 page 12, first paragraph, where a SIP client MUST honor overload control values it receives from downstream neighbors.
      + Section 4.4 page 8, 4th paragraph, following a sequence number overflow, the server must reset the oc-seq parameter. Do we incur the risk of having the client ignore all server requests with the new oc-seq until oc-validity expires? Or does the client need to be able to identify when oc-seq was reset? 
      + Section 7, should there be any mention of draft soc-overload-rate-control?
     
Thanks,

Eric
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Salvatore Loreto [[email-masked]]
Sent: Monday, February 11, 2013 2:34 AM
To: [email-masked]
Cc: Volker Hilt
Subject: Re: [sip-overload] WG Last Call for    draft-ietf-soc-overload-control-12

thanks a lot
Salvatore

Thank you,

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 21 Feb 2013 17:20:25 -0500

OK, finally getting to this.

In section 1, the last paragraph ("this document defines...") seems to 
miss the main point, which is a protocol for COMMUNICATING overload 
information.

Therefore, I would suggest changing

 "  This document defines the general behaviour of SIP servers and
   clients involved in overload control in Section 5.  In addition,
   Section 6 specifies a loss-based overload control scheme.  SIP
   clients and servers conformant to this specification MUST implement
   the loss-based overload control scheme.  They MAY implement other
   overload control schemes as well."

to

"   This document defines the protocol for communicating overload
   information between SIP servers and clients, so that clients can reduce
   the volume of traffic sent to overloaded servers, avoiding congestion
   collapse, and increasing usefull throughput. Section 4 describes the
   Via header parameters used for this communication.  The general
   behaviour of SIP servers and clients involved in overload control
  is described in Section 5.  In addition,
   Section 6 specifies a loss-based overload control scheme.  SIP
   clients and servers conformant to this specification MUST implement
   the loss-based overload control scheme.  They MAY implement other
   overload control schemes as well."

Janet

From:   Salvatore Loreto <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Cc:     Volker Hilt <[email-masked]>
Date:   02/11/2013 02:35 AM
Subject:        Re: [sip-overload] WG Last Call for 
draft-ietf-soc-overload-control-12
Sent by:        [email-masked]

I haven't seen yet any comment or feedback 
please we really need you spend some time to reading and reviewing the 
draft

thanks a lot
Salvatore

The first WGLC that we run ( 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html )
has produced a significant amount of feedback and comments that have been 
discussed and addressed in subsequent versions

Please send your reviews, as well as expression of support regarding 
document readiness for IESG (or not) either to the *soc* mailing list (
[email-masked]), 
or directly to the WG chairs (Murray Kucherawy and myself). 

Thank you, 

_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload