[Sonic HLD] Metering requirements #313
Conversation
| | Metering Buckets per ENI | 4000 | | ||
|
|
||
| ## 1.5 Metering requirements | ||
| Metering is essential for billing the customers and below are the high-level requirements. Metering/Bucket in this context is related to packet counting for billing purposes and not related to traffic policer or shaping. |
There was a problem hiding this comment.
Instead of "packet counting", we should say "byte counting" while "packet counting" is optional
| - All traffic from an ENI to an internet destination | ||
| - All traffic from an ENI to cross-AZ destination (within the same VNET) | ||
| - All traffic from an ENI to cross-region destination (towards the peer VNET) | ||
| - All outbound metered traffic from an ENI |
There was a problem hiding this comment.
How is this "outbound metered traffic" different from the everything listed before it? Should this be "All other" outbound metered traffic....."? When you say implementation, which "implementation"? Is this "HW pipeline", "SW on the DPU", or "the SDN controller"? Also, you could have cross-AZ peer VNET traffic as well, would you not want to count separately as well? I guess I don't understand why you are listing these outbound traffic categories. Is it that these are the ones you want to bill separately?
There was a problem hiding this comment.
All outbound metered traffic means query on ENI + * -> Aggregated counter from all metering buckets associated with ENI. For cross-AZ peer VNET, requirement is to bill as peer VNET. But this is made generic in the modeling that if it requires to be billed differently, it is still possible. Yes, those are the cases that must be billed separately.
I've updated the meaning for "Implementation" in the first usage.
| - All outbound metered traffic from an ENI | ||
| - All inbound metered traffic towards an ENI | ||
| - Customer is billed based on number of bytes sent/received separately. A distinct counter must be supported for outbound vs inbound traffic of each category. | ||
| - For outbound flow and associated metering bucket, created as part of VM initiated traffic, the metering bucket shall account for outbound (Tx) bytes. Based on this outbound flow, pipeline shall also create a unified inbound flow. The same metering bucket shall account for the inbound (Rx) bytes for the return traffic to VM that matches this flow. |
There was a problem hiding this comment.
From scale point of view, there are going be 5M connection and 10M flows (if we count inbound and outbound flows separately). Let's say we support 5M combined unified flows and if the scale required is 4K buckets per ENI, for a total of 64 ENIs, we will have 256K buckets per DPU. Considering we are sharing these buckets across ENIs and across flows, we will be limited to how much we can count separately for each of the categories you have listed above? Is this not true?
There was a problem hiding this comment.
Yes, it is true. But note that many connections may share same bucket id. For example, if there are 100's of mapping for a cross-Az, it will all share the same bucket. However, it is possible that in future we may have to increase the limit from 4k per ENI.
|
/EasyCLA |
| - All traffic from an ENI to cross-region destination (towards the peer VNET) | ||
| - All outbound metered traffic from an ENI | ||
| - All inbound metered traffic towards an ENI | ||
| - Customer is billed based on number of bytes sent/received separately. A distinct counter must be supported for outbound vs inbound traffic of each category. |
There was a problem hiding this comment.
fix terminology: replace inbound/outbound with TX/RX ? since inbound/outbound refers to the first (initiator) packet for the flow
There was a problem hiding this comment.
@vijasrin , i cannot commit to this forked branch anymore after migration. Since its a minor fix, i'll update it in one of the future commits.
|
/EasyCLA |
|
/EasyCLA |
1 similar comment
|
/EasyCLA |
No description provided.