Page History

...

Current state: [One of "Under Discussion", "Accepted", "Rejected"]

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: KAFKA-3492

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

Quota configuration and metrics currently use client-id as the unique key, enforcing one quota for all clients with the same client-id. This will be replaced with a new quota-id. Each quota-id is associated with a pair of producer and consumer rate limits which may be config overrides or the default quota.  

quota.secure=false

• Client-id is used as quota-id (Current implementation)
• Each client–id with a quota override uses the overridden limits
• Each client-id without an override gets the default limits (defaultP, defaultC)

quota.secure=true

• Authenticated principal is used as quota-id if a sub-quota is not specified for the client-id. Otherwise quota-id is the concatenation of principal and client-id. Note that user principals will be base64 encoded hex in the actual implementation, but are shown here as names for readability.

• Example: {user1 : { total: (p1,c1) },  user2 : { total : (p2, c2), clientA : (p2A, c2A), clientB : (p2B, c2B) }}

  • All clients of user1 use the quota-id user1. This shares (p1, c1) amongst the clients of user1 with no individual limits for client-ids.
  • clientA of user2 uses the quota-id user2clientA. This gives clients of user2 with client-id clientA a quota of (p2A, c2A). Similarly for clients with client-id clientB.

  • clientX of user2 uses the quota-id user2. clientY of user2 also uses the same quota-id user2. Hence clientX and clientY share (p2-p2A-p2B, c2-c2A-c2B)
  • All clients of a different user10 use the quota-id user10. This shares (defaultP, defaultC) amongst the clients of user10.

...