Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

From: "Yu, James" <[email-masked]>
Date: Tue, 2 Jul 2013 13:41:59 +0000

Janet,

For my comment on section 3.4 (the first one below), the current text does not provide any value.  The client's arrival rate could be well below the target SIP request rate when its load is light so the fact that the client may not achieve the target SIP request rate (the max. rate it is allowed to send to the server) is well understood.  But with your explanation on the "delta" part, the text then makes sense.  Please add some discussions on the "delta" aspect so that even if the average arrival rate at the client is higher than the target SIP request rate the client at times may not send more than what the target SIP request rate allows due to the fluctuation of the arriving requests at the client.

For the comment on section 3.5.1, I agree with your proposed change.

For the rate control, the server could calculate the arrival rate from each communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server.  But another option is for the client to "optionally" include its calculated arrival rate in its request to the server when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calculations.  This would be beneficial to a server when it receives the requests from many clients.

James

From: Janet P Gunn [mailto:[email-masked]]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

It is a little hard to respond in email when your comments are in a separate document, but here goes.

section 3.4
ID says:
"Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will."

Your comment :
"Not clear what value this paragraph tries to add.  Is it saying that the client's arrival rate may be lower than the target SIP request rate?  "

Yes.

Suppose the server want to limit the total rate of arriving SIP messages to 100 / sec, and has 10 clients.  Each client has a high variance in its message rate, but together they are well above 100 messages per sec

If it sets the rate at 10 messages per second for each of the clients, it will almost certainly end up  with an overall average of less than 100 messages per sec, because some clients will be in a "lull" while others are busy.  This is good from a throttling perspective, but, assuming messages are correlated with revenue, bad/wasteful from a revenue, or overall productivity perspective.  So the server might want to set the rate per client to 10 + delta, where delta is going to be very specific to operating environment.

---
In section  3.5.1, bottom of page 8
ID says:
"And the larger
   the difference between TAU1 and TAU2, the closer to the control is
   to strict priority."

You propose changing it to:
"And the larger
   the difference between TAU1 and TAU2, the closer  the control is
   to strict priority queuing."

I agree with taking out the redundant "to".  But I disagree wit adding "queuing".  There is no queuing, priority or otherwise involved.

You could say:
"And the larger
   the difference between TAU1 and TAU2, the closer  the control is
   to strict priority treatment."

where " strict priority treatment" would refer to the case where non-priority messages are restricted to a total (priority + non-priority) rate of 10 messages per second, but priority messages can continue to be sent as long as the total (priority + non-priority) rate is less than 12 messages per second.

At least, I think that is what Eric and  Philip are trying to say.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

From:        "Yu, James" <[email-masked]<mailto:[email-masked]>>
To:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        06/28/2013 08:10 AM
Subject:        [sip-overload] draft-ietf-soc-overload-rate-control-04.txt
Sent by:        [email-masked]<mailto:[email-masked]>
________________________________

Salvatore,

Please see the attachment for my comments.

I pasted the text to a word document to trace/show the proposed changes and comments.

Regards,

James
 [attachment "comments on draft-ietf-soc-overload-rate-control-04.docx" deleted by Janet P Gunn/USA/CSC] _______________________________________________
sip-overload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sip-overload
________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.2904 / Virus Database: 3204/6452 - Release Date: 06/30/13

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Tue, 9 Jul 2013 16:44:08 -0400

Janet, James,

Thanks you for your valuable comments and discussion.  I tried to capture all resolution in the following text (based on James word document with track changes and imbedded comments enabled).

+ Abstract section:
- Agreed with suggested changes
- Please note I will also need to make further changes to remove all references per Christer Holmberg comment

+ Section 1:
- Agreed with suggested changes

+ Section 3.1:
- Agreed with suggested changes

+ Section 3.2: - Please note the section title will become "Via header field parameters for overload control " per Christer Holmberg comment
- Agreed with suggested changes excluding title that will change per previous bullet

+ Section 3.3:
- Agreed with suggested changes

+ Section 3.4:
- ID:  "Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will."
   [JY] Not clear what value this paragraph tries to add.  Is it saying that the client's arrival rate may be lower than the target SIP request rate?
   [JG] Yes + supporting example (see below in thread)
  Agreed with Janet and supporting example. Per James request, I will add the following text (inspired from Janet's illustrative example):
   "In other words, when multiple clients are being controlled by an overloaded server, at any given time some clients may receive requests at a rate below its target SIP request rate while others above that target rate. But the resulting request rate presented to the overloaded server will converge towards the target SIP request rate."
- Agreed with other suggested changes

+ Section 3.5.1:
- ID: "And the larger the difference between TAU1 and TAU2, the closer to the control is to strict priority."
  [JY] Suggest changing into "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority queuing."
  [JG] Suggest changing into "And the larger the difference between TAU1 and TAU2, the closer the control is to strict priority treatment."
  [EN] Agreed with Janet's suggestion
- Agreed with other suggested changes

+ Section 4:
- Agreed with suggested changes

+ Section 5:
- Please note that based comments from per Christer Holmberg and Janet Gunn, the following was tentatively agreed
   Replace oc-value = "NaN" / oc-num    by    oc = "oc" [EQUAL oc-num]
- Agreed with other suggested change

+ Section 7:
- [JY] Should "rate" in oc-algo be registered with IANA?
  This issue needs to be addressed by draft-ietf-soc-overload-control authors

Please note I will wait until expiration of WGLC prior updating our draft RFC. Once again your comments and/or suggestions are most appreciated.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "Yu, James" <[email-masked]>
Date: Wed, 10 Jul 2013 13:00:35 +0000

Noel,

I mentioned in my message to Janet on 7/2:

I suggest that the I-D adds that option to allow the client to indicate its current arrival rate (towards the receiving server) in the SIP request.

James

From: NOEL, ERIC C (ERIC C) [mailto:[email-masked]]
Sent: Tuesday, July 09, 2013 4:44 PM
To: Yu, James; Janet P Gunn
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Yu, James
Sent: Tuesday, July 02, 2013 9:42 AM
To: Janet P Gunn
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Janet,

James

From: Janet P Gunn [mailto:[email-masked]]
Sent: Friday, June 28, 2013 3:34 PM
To: Yu, James
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James
Version: 2013.0.2904 / Virus Database: 3204/6478 - Release Date: 07/09/13

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 10 Jul 2013 10:11:36 -0400

I thought I understood that the point of this rate based algorithm ID  was 
to "piggy back" on the communications  protocol parameters defined in the 
loss based algorithm ID (oc, oc-algo, oc-num, oc-validity, oc-seq), 
introducing new parameter VALUES, but not new parameters.

In order to convey the "current arrival rate of messages intended for you" 
from the client to the server, you would need to add new parameters,  or 
use existing parameters in a way that would cause problems for  the loss 
based version.

Furthermore, when the client is receiving, and therefore sending, messaged 
intended for this server, at a rate lower than the current specified rate 
limit, the server can deduce that directly, and adjust the specific rate 
limit it sends to (this or other) clients if it wants to.

I think that would be much "cleaner" (and probably more effective as 
well), than adding new parameters, or making major changes to the 
communications protocol in the loss based algorithm ID.

Janet

[email-masked] wrote on 07/10/2013 09:00:35 AM:

> From: "Yu, James" <[email-masked]>
> To: "NOEL, ERIC C (ERIC C)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,
> "[email-masked]" <draft-
> [email-masked]>, "sip-
> [email-masked]" <[email-masked]>
> Date: 07/10/2013 09:01 AM
> Sent by: [email-masked]
> 
> Noel,
> 
> For the rate control, the server could calculate the arrival rate 
> from each communicating client so that it could allocate the overall
> target SIP request rate to the clients based on their arrival rates 
> known to the server.  But another option is for the client to 
> “optionally” include its calculated arrival rate in its request to 
> the server when rate control related parameters are present.  Should
> this option be evaluated/included to relieve the server from doing 
> the arrival rate calculations.  This would be beneficial to a server
> when it receives the requests from many clients.
> 
> I suggest that the I-D adds that option to allow the client to 
> indicate its current arrival rate (towards the receiving server) in 
> the SIP request.
> 
> James
> 
> Cc: [email-masked]; draft-ietf-soc-overload-rate-
> [email-masked]; [email-masked]
> Thanks you for your valuable comments and discussion.  I tried to 
> capture all resolution in the following text (based on James word 
> document with track changes and imbedded comments enabled).
> 
> + Abstract section: 
> + Section 3.2: - Please note the section title will become “Via 
> header field parameters for overload control “ per Christer Holmberg 
comment
> - ID:  "Note that the target SIP request rate is a max rate that may
> not be attained by the arrival rate at the client, and the server 
> cannot assume that it will." 
>    [JY] Not clear what value this paragraph tries to add.  Is it 
> saying that the client's arrival rate may be lower than the target 
> SIP request rate? 
>   Agreed with Janet and supporting example. Per James request, I 
> will add the following text (inspired from Janet’s illustrative 
example):
>    “In other words, when multiple clients are being controlled by an
> overloaded server, at any given time some clients may receive 
> requests at a rate below its target SIP request rate while others 
> above that target rate. But the resulting request rate presented to 
> the overloaded server will converge towards the target SIP request 
rate.”
> - ID: “And the larger the difference between TAU1 and TAU2, the 
> closer to the control is to strict priority.”
>   [JY] Suggest changing into “And the larger the difference between 
> TAU1 and TAU2, the closer the control is to strict priority queuing.”
>   [JG] Suggest changing into “And the larger the difference between 
> TAU1 and TAU2, the closer the control is to strict priority treatment.”
>   [EN] Agreed with Janet’s suggestion
> - Please note that based comments from per Christer Holmberg and 
> Janet Gunn, the following was tentatively agreed 
> - [JY] Should “rate” in oc-algo be registered with IANA?
> Please note I will wait until expiration of WGLC prior updating our 
> draft RFC. Once again your comments and/or suggestions are most 
appreciated.
> [email-masked]
> From: [email-masked] [
mailto:[email-masked]] 
> On Behalf Of Yu, James
> Cc: [email-masked]; draft-ietf-soc-overload-rate-
> [email-masked]; [email-masked]
> For my comment on section 3.4 (the first one below), the current 
> text does not provide any value.  The client’s arrival rate could be
> well below the target SIP request rate when its load is light so the
> fact that the client may not achieve the target SIP request rate 
> (the max. rate it is allowed to send to the server) is well 
> understood.  But with your explanation on the “delta” part, the text
> then makes sense.  Please add some discussions on the “delta” aspect
> so that even if the average arrival rate at the client is higher 
> than the target SIP request rate the client at times may not send 
> more than what the target SIP request rate allows due to the 
> fluctuation of the arriving requests at the client.
> 
> For the rate control, the server could calculate the arrival rate 
> from each communicating client so that it could allocate the overall
> target SIP request rate to the clients based on their arrival rates 
> known to the server.  But another option is for the client to 
> “optionally” include its calculated arrival rate in its request to 
> the server when rate control related parameters are present.  Should
> this option be evaluated/included to relieve the server from doing 
> the arrival rate calculations.  This would be beneficial to a server
> when it receives the requests from many clients.
> 
> James
> 
> Cc: [email-masked]; sip-
> [email-masked]; [email-masked]
> "Not clear what value this paragraph tries to add.  Is it saying 
> that the client's arrival rate may be lower than the target SIP 
> request rate?  " 
> 
> Yes. 
> 
> Suppose the server want to limit the total rate of arriving SIP 
> messages to 100 / sec, and has 10 clients.  Each client has a high 
> variance in its message rate, but together they are well above 100 
> messages per sec 
> 
> If it sets the rate at 10 messages per second for each of the 
> clients, it will almost certainly end up  with an overall average of
> less than 100 messages per sec, because some clients will be in a 
> "lull" while others are busy.  This is good from a throttling 
> perspective, but, assuming messages are correlated with revenue, 
> bad/wasteful from a revenue, or overall productivity perspective. 
> So the server might want to set the rate per client to 10 + delta, 
> where delta is going to be very specific to operating environment. 
> 
> --- 
> I agree with taking out the redundant "to".  But I disagree wit 
> adding "queuing".  There is no queuing, priority or otherwise involved. 
> 
> You could say: 
> "And the larger 
> where " strict priority treatment" would refer to the case where 
> non-priority messages are restricted to a total (priority + non-
> priority) rate of 10 messages per second, but priority messages can 
> continue to be sent as long as the total (priority + non-priority) 
> rate is less than 12 messages per second. 
> 
> This is a PRIVATE message. If you are not the intended recipient, 
> please delete without copying and kindly advise us by e-mail of the 
> mistake in delivery. NOTE: Regardless of content, this e-mail shall 
> not operate to bind CSC to any order or other contract unless 
> pursuant to explicit written agreement or government initiative 
> expressly permitting the use of e-mail for such purpose. 
> 
> 
> 
> From:        "Yu, James" <[email-masked]> 
> To:        "[email-masked]" 
<[email-masked]>, "
> [email-masked]" <draft-
> [email-masked]>, 
"[email-masked]" <
> [email-masked]> 
> Subject:        [sip-overload] 
draft-ietf-soc-overload-rate-control-04.txt 
> Sent by:        [email-masked] 
> 
> 
> 
> 
> Salvatore, 
> 
>  [attachment "comments on draft-ietf-soc-overload-rate-
> control-04.docx" deleted by Janet P Gunn/USA/CSC] 
> _______________________________________________
> [email-masked]
> Checked by AVG - www.avg.com
> Checked by AVG - www.avg.com
> _______________________________________________
> [email-masked]

---

From: "Yu, James" <[email-masked]>
Date: Wed, 10 Jul 2013 14:17:02 +0000

Noel,

I forgot to respond to your reply about the IANA registration of "rate" in oc-algo.  I see that draft-ietf-soc-overload-control-13 mentions your I-D but does not have "rate" in algo-list.

There are two possible ways to address "rate" in algo-list.  One is to have draft-ietf-soc-overload-control-13 add "rate" to algo-list and refer to your I-D for details.  The other is to register "rate" in algo-list with IANA in your I-D, and this should be a simple task.  The cleaner way that is more inline with the IETF process would be the latter.  It seems odd to have something defined in a RFC without details about it, and it would be too much trouble to combine the two I-Ds.

James

From: Yu, James
Sent: Wednesday, July 10, 2013 9:01 AM
To: 'NOEL, ERIC C (ERIC C)'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "Yu, James" <[email-masked]>
Date: Wed, 10 Jul 2013 14:23:20 +0000

Janet,

I agree with you that using the existing parameters would cause problems for the loss based version and adding new parameters at this stage would delay this I-D.  I’ll drop this comment.

James

From: Janet P Gunn [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 10:12 AM
To: Yu, James
Cc: [email-masked]; NOEL, ERIC C (ERIC C); [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

I thought I understood that the point of this rate based algorithm ID  was to "piggy back" on the communications  protocol parameters defined in the loss based algorithm ID (oc, oc-algo, oc-num, oc-validity, oc-seq), introducing new parameter VALUES, but not new parameters.

In order to convey the "current arrival rate of messages intended for you" from the client to the server, you would need to add new parameters,  or use existing parameters in a way that would cause problems for  the loss based version.

Furthermore, when the client is receiving, and therefore sending, messaged intended for this server, at a rate lower than the current specified rate limit, the server can deduce that directly, and adjust the specific rate limit it sends to (this or other) clients if it wants to.

I think that would be much "cleaner" (and probably more effective as well), than adding new parameters, or making major changes to the communications protocol in the loss based algorithm ID.

Janet

[email-masked]<mailto:[email-masked]> wrote on 07/10/2013 09:00:35 AM:

> To: "NOEL, ERIC C (ERIC C)" <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>" <draft-
> [email-masked]<mailto:[email-masked]>>, "sip-
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-soc-overload-rate-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> header field parameters for overload control “ per Christer Holmberg comment
> will add the following text (inspired from Janet’s illustrative example):
> the overloaded server will converge towards the target SIP request rate.”
> draft RFC. Once again your comments and/or suggestions are most appreciated.
>
> Thanks,
>
> Eric Noel
> AT&T Labs, Inc.
> Rethink Possible
>
> [email-masked]<mailto:[email-masked]>
>
> Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-soc-overload-rate-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; sip-
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> To:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <draft-
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 10 Jul 2013 10:34:12 -0400

James,

My apologies for having missed your comment.

"For the rate control, the server could calculate the arrival rate from each communicating client so that it could allocate the overall target SIP request rate to the clients based on their arrival rates known to the server. "
[EN] Yes, instead of uniformly distributed target SIP request rate across clients, the overloaded server could distributed the request rate function of the requests it gets from the clients.
In our propose we eluded to your suggestion through the following sentence (section 3.4):
"The server must allocate a portion of the target SIP request rate to each of its client. The server may set the same rate for every client, or may set different rates for different clients."

"But another option is for the client to "optionally" include its calculated arrival rate in its request to the server when rate control related parameters are present.  Should this option be evaluated/included to relieve the server from doing the arrival rate calculations.  This would be beneficial to a server when it receives the requests from many clients."
[EN] Your suggestion is currently not supported by draft-ietf-soc-overload-control (there are no parameters that would allow clients to inform server of their respective arrival rates) from which draft-ietf-soc-overload-rate-control depends upon. You may want to propose this option to draft-ietf-soc-overload-control authors. But in practice, servers estimate percent blocking or rate dynamically based on their overload state so as to have clients throttle at a level close to servers overload onset level.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: Yu, James [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 9:01 AM
To: NOEL, ERIC C (ERIC C)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 10 Jul 2013 10:48:31 -0400

James,

Thank you for your suggestion.

Not being familiar with IANA procedure, would updating draft-ietf-soc-overload-rate-control section 7 (IANA considerations) as follows work?

This specification defines a new value for Via header parameter oc-algo as detailed below in the "Header Field Parameter and Parameter Values" subregistry as per the registry created by [RFC3968]. The required information is:

Header Field           Parameter Name                        Predefined Values                    Reference
----------------------------------------------------------------------------------------------------------
Via                              oc-algo                                              "rate"                                             RFCXXXX

RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC number of this specification.]

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Sent: Wednesday, July 10, 2013 10:17 AM

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "Yu, James" <[email-masked]>
Date: Wed, 10 Jul 2013 15:35:30 +0000

Eric,

Yes, this adds "rate" to "oc-algo" parameter but please check with IANA to see if it is the correct way.  You also need to copy some syntax lines from the draft-ietf-soc-overload-control to show

     algo-list   = "loss" / "rate" / *(other-algo)

I've an email to Henning asking if algo-list in his I-D should be
     algo-list   = "loss" / other-algo

If yes, then this particular line in your I-D would be
     algo-list   = "loss" / "rate" / other-algo

James

From: NOEL, ERIC C (ERIC C) [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 10:49 AM
To: Yu, James
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 10 Jul 2013 13:10:09 -0400

James,

Based on your suggestion and comments from other reviewers, I intend to update section 5 (syntax) as follows:

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

algo-list = "loss" / "rate" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39

I understand there may be an additional change following Henning's reply.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Sent: Wednesday, July 10, 2013 11:36 AM

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "Yu, James" <[email-masked]>
Date: Wed, 10 Jul 2013 19:09:42 +0000

Eric,

You may want to copy the "oc-algo" line from other I-D.

James

From: NOEL, ERIC C (ERIC C) [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 1:10 PM
To: Yu, James
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 10 Jul 2013 15:54:07 -0400

James,

So section 5 (syntax) will include the following statements:

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE
algo-list = "loss" / "rate" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Sent: Wednesday, July 10, 2013 3:10 PM

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 10 Jul 2013 22:04:38 +0000

I've lost track of what is happening here. What I expect is two things:

1)         IANA registration impact.

For the header field parameters registry, draft-ietf-soc-overload-control already creates the new rows:

       __________________________________________________________

       Via           oc                 Yes             RFCXXXX

       Via           oc-validity        Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

       RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC

       number of this specification.]

For the predefined values columns, RFC 3968 states:

   Some SIP header field parameters only accept a set of predefined

   parameter values.  For example, a parameter indicating the transport

   protocol in use may only accept the predefined tokens TCP, UDP, and

   SCTP as valid values.  Registering all parameter values for all SIP

   header field parameters of this type would require a large number of

   subregistries.  Instead, we have chosen to register parameter values

   by reference.  That is, the entry in the parameter registry for a

   given header field parameter contains references to the RFCs defining

   new values of the parameter.  References to RFCs defining parameter

   values appear in double brackets in the registry.

   So, the header field parameter registry contains a column that

   indicates whether or not each parameter only accepts a set of

   predefined values.  Implementers of parameters with a "yes" in that

   column need to find all the valid parameter values in the RFCs

   provided as references.

With this understanding, I do not believe the rate-control draft needs to modify the "predefined values" column. What it does need to do is add its ultimate RFC number to the reference column.

There could be an argument that there needs to be a new table that lists the algorithm values, but

a)                   if such a table is to be created, it needs to be created by draft-ietf-soc-overload-control rather than the rate-control draft/
b)                   I personally do not think it is necessary to add such a new table, as I think the references are sufficient. One cannot handle the algorithm values unless one goes to the relevant RFC.

2)         ABNF impact.

ABNF defines the /= operator for adding new values to an existing defined list.

I do not think we should reproduce existing ABNF from draft-ietf-soc-overload-control and then amend it.

The reason for this is that tools exist for automatically extracting the ABNF from RFCs. An extracted

algo-list /= "rate"

will work perfectly well with the extract from draft-ietf-soc-overload-control (and from SIP). Reproducing productions will result in conflict.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of NOEL, ERIC C (ERIC C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 10 Jul 2013 22:08:04 +0000

2 additions.

For /= read =/

For adding the new parameters to the Via header field, draft-ietf-soc-overload control should also use =/ (it is not a problem of rate control to fix this issue.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 10 July 2013 23:05
To: NOEL, ERIC C (ERIC C); 'Yu, James'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

       Via           oc                 Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

   provided as references.

2)         ABNF impact.

algo-list /= "rate"

Regards

Keith

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Thu, 11 Jul 2013 14:32:42 -0400

Keith,

Thank you for your comment.

IANA impacts:
- Based on Keith suggestion, for the IANA impacts we only need to have the IANA consideration section in draft-ietf-soc-overload-control to include the future RFC number for draft-ietf-soc-overload-rate-control in the reference column
- While James is suggesting explicitly defining the new parameter value in the IANA consideration section of draft-ietf-soc-overload-rate-control
=> Because Keith proposal is aligned with RFC 3968 guidelines, I propose adopting his proposal.

ABNF impacts:
- Based on Keith suggestion, draft-ietf-soc-overload-rate-control syntax section should be reduced to
algo-list /= "rate"
- While James is suggesting that section to include
oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) DQUOTE
algo-list = "loss" / "rate" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39
=> Per Keith suggestion, to prevent potential conflicts, I propose adopting his proposal.

James would you agree with the proposed resolution?

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, July 10, 2013 6:05 PM
To: NOEL, ERIC C (ERIC C); 'Yu, James'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

       Via           oc                 Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

   provided as references.

2)         ABNF impact.

algo-list /= "rate"

Regards

Keith

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jul 2013 11:03:53 +0000

Hi Eric,

In an e-mail you said that you will wait for "WGLC expiration" before you submit a new version of the draft.

But, WGLC will not "expire" until we have a draft which addresses the raised issues :)

So, if you think the issues have been solved, I would suggest that you submit a new version of the draft, where the solutions are implemented, so that people can take a look.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jul 2013 11:10:40 +0000

Hi,

I support Keith's suggestion. There is no need to copy/paste syntax from another specification - we should simply define the syntax additions/extensions.

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta NOEL, ERIC C (ERIC C)
Lähetetty: 11. heinäkuuta 2013 21:33
Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James'
Kopio: [email-masked]; [email-masked]; [email-masked]
Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Keith,

IANA impacts:

ABNF impacts:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

       Via           oc                 Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

   provided as references.

2)         ABNF impact.

algo-list /= "rate"

Regards

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of NOEL, ERIC C (ERIC C)
Sent: 10 July 2013 20:54
To: 'Yu, James'
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 22 Jul 2013 09:30:26 -0400

Christer,

I believe I addressed all the issues and will send an updated version shortly to finalize the WGLC.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Optimization, Reliability and Customer Analytics
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[email-masked]<mailto:[email-masked]>

From: Christer Holmberg [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 7:04 AM
To: NOEL, ERIC C (ERIC C)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Hi Eric,

Regards,

Christer

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 22 Jul 2013 09:38:44 -0400

Christer,

Thanks for the follow-up.

We had off line email exchanges between Keith Drage and James Yu on this issue (I just realize I forgot to post the resolution).

The following was agreed:

Update Section 7, "IANA Considerations":
       Header             Field  Parameter Name        Predefined  Values           Reference
       _________________________________________________________________
       Via                    oc-algo                                           Yes                                           RFCABCD RFCOPRQ
RFCABCD RFCOPRQ [NOTE TO RFC-EDITOR: Please replace with final RFC number of draft-ietf-soc-overload-rate-control & draft-ietf-soc-overload-control]

Update Section 5, "Syntax":
This specification extends the existing definition of the Via header field parameters of [RFC3261] as follows:
algo-list /= "rate"

And no additional changes related to the above will be required in draft-ietf-soc-overload-control.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: Christer Holmberg [mailto:[email-masked]]
Sent: Saturday, July 20, 2013 7:11 AM
To: NOEL, ERIC C (ERIC C); 'DRAGE, Keith (Keith)'; 'Yu, James'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: VS: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Hi,

Regards,

Christer

Keith,

IANA impacts:

ABNF impacts:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

       Via           oc                 Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

   provided as references.

2)         ABNF impact.

algo-list /= "rate"

Regards

Keith

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jul 2013 13:57:06 +0000

Hi,

The resolution looks fine to me.

Regards,

Christer

Lähettäjä: NOEL, ERIC C (ERIC C) [mailto:[email-masked]]
Lähetetty: 22. heinäkuuta 2013 16:39
Vastaanottaja: Christer Holmberg; 'DRAGE, Keith (Keith)'; 'Yu, James'
Kopio: [email-masked]; [email-masked]; [email-masked]
Aihe: RE: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Christer,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Hi,

Regards,

Christer

Lähettäjä: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Puolesta NOEL, ERIC C (ERIC C)
Lähetetty: 11. heinäkuuta 2013 21:33
Vastaanottaja: 'DRAGE, Keith (Keith)'; 'Yu, James'
Kopio: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Aihe: Re: [sip-overload] draft-ietf-soc-overload-rate-control-04.txt

Keith,

IANA impacts:

ABNF impacts:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

       Via           oc                 Yes             RFCXXXX

       Via           oc-seq             Yes             RFCXXXX

       Via           oc-algo            Yes             RFCXXXX

   provided as references.

2)         ABNF impact.

algo-list /= "rate"

Regards

Keith

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Eric,

James

James,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Noel,

James

From: Yu, James

Noel,

James

Janet, James,

+ Abstract section:

+ Section 1:

+ Section 3.1:

+ Section 3.3:

+ Section 3.4:

+ Section 3.5.1:

+ Section 4:

+ Section 5:

+ Section 7:

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Janet,

James

James,

section 3.4
ID says:

Your comment :

Yes.

---

You could say:
"And the larger

Janet

Salvatore,

Regards,

James

---

From: "Yu, James" <[email-masked]>
Date: Mon, 22 Jul 2013 19:18:12 +0000

Hi, Henning, Vijay, Volker,

When I reviewed draft-ietf-soc-overload-rate-control-04.txt, I glanced through the syntax in this I-D to understand the oc related parameters.

When looking at "algo-list", I wonder if there are two "other-algo" such as "abc" and "xyz", 'abc" and "xyz" won't be comma-separated based on the oc-algo syntax.  It seems that algo-list would be

This would ensure that one and only one algorithm is present in algo-list.  If there is no algorithm other than "loss", *(COMMA algo-list) would take care of that.

Since algo-list contains a single algorithm, may be it is better to use "algo" only.  Or if algo-list contains a list of comma separated algorithms, then alog-list and oc-algo can be modified so that oc-algo has a single "algo-list".  The latter may be better because the current syntax would allow the same algorithm to appear more than once.

James

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Jul 2013 14:43:16 -0500

James: This is a quick ack of your email.  It is on my list of
things to do.  I will circle back on it sometimes next week.

Cheers,

On 07/22/2013 02:18 PM, Yu, James wrote:
> When I reviewed draft-ietf-soc-overload-rate-control-04.txt, I glanced
> through the syntax in this I-D to understand the oc related parameters.
>
> When looking at “algo-list”, I wonder if there are two “other-algo” such
> as “abc” and “xyz”, ‘abc” and “xyz” won’t be comma-separated based on
> the oc-algo syntax.  It seems that algo-list would be
>
>   algo-list = “loss“/ other-algo
>
> This would ensure that one and only one algorithm is present in
> algo-list.  If there is no algorithm other than “loss”, *(COMMA
> algo-list) would take care of that.
>
> Since algo-list contains a single algorithm, may be it is better to use
> “algo” only.  Or if algo-list contains a list of comma separated
> algorithms, then alog-list and oc-algo can be modified so that oc-algo
> has a single “algo-list”.  The latter may be better because the current
> syntax would allow the same algorithm to appear more than once.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 22 Jul 2013 15:53:45 -0400

There is at least one "other-algo", "rate".

When algo-list is included in the Via headers of a message sent by the 
client to the server, it may have multiple algorithms included in the 
algo-list - all the algorithms supported by the client.

When algo-list is included in the Via headers sent from the server to the 
client, it should have " one and only one algorithm" in the list.

Janet

From:   "Yu, James" <[email-masked]>
To:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
Cc:     "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:   07/22/2013 03:19 PM
Subject:        [sip-overload]  draft-ietf-soc-overload-control-13
Sent by:        [email-masked]

 
When looking at “algo-list”, I wonder if there are two “other-algo” such 
as “abc” and “xyz”, ‘abc” and “xyz” won’t be comma-separated based on the 
oc-algo syntax.  It seems that algo-list would be 
 
 algo-list = “loss“ / other-algo
 
This would ensure that one and only one algorithm is present in algo-list. 
 If there is no algorithm other than “loss”, *(COMMA algo-list) would take 
care of that.
 
Since algo-list contains a single algorithm, may be it is better to use 
“algo” only.  Or if algo-list contains a list of comma separated 
algorithms, then alog-list and oc-algo can be modified so that oc-algo has 
a single “algo-list”.  The latter may be better because the current syntax 
would allow the same algorithm to appear more than once.
 
James_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Yu, James" <[email-masked]>
Date: Mon, 22 Jul 2013 20:11:54 +0000

Janet,

My comment is not on having multiple algorithms in the via header but on the syntax in the current I-D that could allow multiple algorithms that are not separated by “,”.  Please check the syntax by having “rate” and “foo”.

James

From: Janet P Gunn [mailto:[email-masked]]
Sent: Monday, July 22, 2013 3:54 PM
To: Yu, James
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13

When algo-list is included in the Via headers of a message sent by the client to the server, it may have multiple algorithms included in the algo-list - all the algorithms supported by the client.

When algo-list is included in the Via headers sent from the server to the client, it should have " one and only one algorithm" in the list.

Janet

From:        "Yu, James" <[email-masked]<mailto:[email-masked]>>
To:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        07/22/2013 03:19 PM
Subject:        [sip-overload]  draft-ietf-soc-overload-control-13
Sent by:        [email-masked]<mailto:[email-masked]>
________________________________

When looking at “algo-list”, I wonder if there are two “other-algo” such as “abc” and “xyz”, ‘abc” and “xyz” won’t be comma-separated based on the oc-algo syntax.  It seems that algo-list would be

This would ensure that one and only one algorithm is present in algo-list.  If there is no algorithm other than “loss”, *(COMMA algo-list) would take care of that.

Since algo-list contains a single algorithm, may be it is better to use “algo” only.  Or if algo-list contains a list of comma separated algorithms, then alog-list and oc-algo can be modified so that oc-algo has a single “algo-list”.  The latter may be better because the current syntax would allow the same algorithm to appear more than once.

Version: 2013.0.2904 / Virus Database: 3204/6510 - Release Date: 07/22/13

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Jul 2013 03:54:44 +0000

Hi,

I don’t think the current ABNF allows a list without comma separation. Keep in mind that “algo-list” does not represent the list, only a single value in the list.

But, I understand your confusion, and in fact I think ”algo-list” is a little misleading. I think it would be better to call it “algo-value”, or something similar.

oc-algo     = "oc-algo" EQUAL DQUOTE algo-value *(COMMA algo-value)DQUOTE
algo-value   = "loss" / *(other-algo)
other-algo  = %x41-5A / %x61-7A / %x30-39

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Yu, James
Lähetetty: 22. heinäkuuta 2013 23:12
Vastaanottaja: Janet P Gunn
Kopio: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Aihe: Re: [sip-overload] draft-ietf-soc-overload-control-13

Janet,

James

From: Janet P Gunn [mailto:[email-masked]]
Sent: Monday, July 22, 2013 3:54 PM
To: Yu, James
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-control-13

Janet

---

From: "Yu, James" <[email-masked]>
Date: Wed, 31 Jul 2013 13:47:22 +0000

Christer,

Sorry for a late reply.  I was just back from vacation.

I am wondering if it should be

       algo-value = “loss” / other-algo

where algo-value would only contain a single algorithm value such as “loss” or something else.

When a new algorithm such as “rate” is added, it becomes

       algo-value = “loss” / “rate” / other-algo

James

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, July 22, 2013 11:55 PM
To: Yu, James; Janet P Gunn
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: VS: [sip-overload] draft-ietf-soc-overload-control-13

Hi,

Regards,

Christer

Lähettäjä: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Puolesta Yu, James
Lähetetty: 22. heinäkuuta 2013 23:12
Vastaanottaja: Janet P Gunn
Kopio: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Aihe: Re: [sip-overload] draft-ietf-soc-overload-control-13

Janet,

James

Janet

Version: 2013.0.2904 / Virus Database: 3209/6536 - Release Date: 07/30/13

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jul 2013 14:47:23 +0000

Hi,

> where algo-value would only contain a single algorithm value such as “loss” or something else.

Keep in mind that the definition of other-algo is only a single character.

But, we can change other-algo to:

other-algo  = 1*(%x41-5A / %x61-7A / %x30-39)

…which probably clarifies even further.

Regards,

Christer

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi,

Regards,

Christer

Janet,

James

Janet

---

From: "Yu, James" <[email-masked]>
Date: Wed, 31 Jul 2013 18:05:26 +0000

I agree with the change.

James

From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, July 31, 2013 10:47 AM
To: Yu, James
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: VS: [sip-overload] draft-ietf-soc-overload-control-13

Hi,

Regards,

Christer

Hi,

Regards,

Christer

Janet,

James

Janet