Session Initiation Protocol (SIP) Rate Control
RFC 7415

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

(Richard Barnes; former steering group member) Yes

Yes ()
No email
send info

(Spencer Dawkins; former steering group member) Yes

Yes (2014-10-16)
No email
send info
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 steering group member) No Objection

No Objection ()
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ()
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection ()
No email
send info

(Benoît Claise; former steering group member) No Objection

No Objection ()
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ()
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ()
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ()
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ()
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (2014-10-15)
No email
send info
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 steering group member) No Objection

No Objection ()
No email
send info

(Ted Lemon; former steering group member) No Objection

No Objection ()
No email
send info