Skip to main content

Session Initiation Protocol (SIP) Rate Control
draft-ietf-soc-overload-rate-control-10

Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Stephen Farrell)
(Ted Lemon)

Note: This ballot was opened for revision 10 and is now closed.

Richard Barnes Former IESG member
Yes
Yes () Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2014-10-16) Unknown
Thanks for producing this draft. It’s important.

I did have one question.

In this text, in 3.5.1. Default algorithm:

  TAU=4*T is a reasonable compromise between burst size and throttled
   rate adaptation at low offered rates.

will this always be true for SIP (so, “is”), or is there an appropriate qualifier that could be included?
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection () Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection () Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection () Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection () Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2014-10-15) Unknown
3.3 - Isn't the second paragraph completely redundant with the first? Why not remove it?

3.4 - What is the first sentence of the second paragraph trying to tell the implementer? That it can't lower the rate based on something other than overload state? That it has to do it "periodically", whatever that means? I don't get it.

   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 their target (maximum) SIP request rate
   while others above that target rate.

The *server* receives the request, not the client, right? I don't understand this sentence.

The second to last paragraph also seems redundant. Can it be removed?

3.5.1/3.5.2/3.5.3 - The language of "admitted/rejected" had me confused for a bit because it's talking about the client, which I think of as "sending/not-sending" requests; the server is the one doing the admitting (accepting) vs. rejecting. If SIP folks are used to this language, I guess it's fine, but it did take a reset when I first read it.
Stephen Farrell Former IESG member
No Objection
No Objection () Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection () Unknown