[tsvwg] Re: WGLC review of draft-ietf-tsvwg-nqb-23

[Martin Duke <[e-mail]>]

Sorry for the delay. replies inline.

On Fri, May 31, 2024 at 3:50 PM Greg White <[e-mail]> wrote:

> Hi Martin,
>
>
>
> Thanks for your review and comments.
>
>
>
> To your point about relying heavily on “magic” numbers with unclear future
> evolution.  I’ve tried to pull out all of the potential instances here:
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.1
>
> ~1% of “typical” network path capacity - This is explicitly defined as
> being relative to “typical” network capacity in order that it can evolve
> over time. I believe that we reached consensus on the 1% number.
>
>
>
> “R*T + 1500 bytes” – based on the typical Internet MTU.
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-4.4.1
>
> “the policer/shaper rate SHOULD be set to either 5% of the interconnection
> data rate, or 5% of the typical rate for such interconnections, whichever
> is greater. …. The recommendation to limit NQB traffic to 5% is based on an
> assumption that internal links in the downstream domain could have data
> rates as low as one tenth of the interconnect rate, in which case if the
> entire aggregate of NQB traffic traversed a single instance of such a link,
> the aggregate would consume no more than 50% of that link's capacity. This
> SHOULD be adjusted based on any knowledge of the local network environment
> that is available.” – automatically scales based on interconnection data
> rates, and guidance is given on further adjustment for local network
> conditions.
>
>
>
> “A traffic policing function SHOULD allow approximately 100 ms of burst
> tolerance (e.g. a token bucket depth equal to 100 ms multiplied by the
> policer rate). A traffic shaping function SHOULD allow approximately 10 ms
> of burst tolerance, and no more than 50 ms of buffering.” – provided in
> time units as opposed to byte units so that they automatically scale with
> link rates.
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.1
>
> “It is RECOMMENDED to configure an NQB buffer size less than or equal to
> 10 ms at the shared NQB/Default egress rate.”  - as above, written in time
> units so as to automatically scale with link rates.
>
>
>
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.3
>
> “However, it would not seem necessary to limit bursts lower than roughly
> 10% of the minimum base RTT expected in the typical deployment scenario” –
> expressed relative to contemporaneous conditions
>
>
>
>
>
> So, for the primary link characteristic that is expected to evolve over
> time (data rate), I think we’re good.  It is clear how the parameters track
> network evolution.  The “1500 bytes” probably could be replaced with
> “MTU”.  The others seem to be the parameters provided in time units. Are
> those the ones that you are concerned about?
>

[MD] I'm seeing specific bps numbers in Sec 4.1, but looking again, I
believe these numbers are current values used as an example rather than
normative values.

The 10ms figure seems reasonable, but of course that builds in assumptions
about future applications. But I suppose that's fine.


>
>
> Other responses below [GW].
>
>
>
>
>
>
>
> *From: *Martin Duke <[e-mail]>
> *Date: *Tuesday, May 28, 2024 at 5:24 PM
> *To: *tsvwg <[e-mail]>
> *Subject: *[tsvwg] WGLC review of draft-ietf-tsvwg-nqb-23
>
>
>
> - This document appears to rely heavily on magic numbers derived from
> current link characteristics, and it's not clear how those can evolve over
> time. There's some loose language about traffic policing and appropriate
> responses to that. DSCP is a somewhat more loosely defined area than
> others, but I was hoping for a little more precision in a standard.
>
>
>
> [GW] Yes, other standard PHB specs leave quite a bit of flexibility as
> well.  Is there something specific that you’d like to see changed?
>

[MD] This is now just an editorial comment, but perhaps a more careful
separation of what is normative here and what is an example based on the
current internet?


>
>
> - I wonder if keeping a token bucket is really needed, or just keeping a
> very small queue and looking at what flows are filling up that queue is
> sufficient to identify bad actors.
>
>
>
> [GW] I’m not sure I follow this comment. The only direct discussion of a
> token bucket is in the section on handling situations where a downstream
> domain might provide DSCP 45 with high priority.  In that context, we do
> suggest traffic protection (i.e. looking at what flows are filling up the
> queue), but since the “queue” at the egress into the downstream domain may
> not be the bottleneck, we also discuss rate shaping/policing the aggregate
> of NQB traffic (in which case a token bucket seems reasonable).
>  Identifying bad actors is a role for a traffic protection algorithm, for
> which we don’t directly discuss keeping a token bucket. Perhaps you are
> inferring a token bucket from the discussion about potentially using a
> per-flow rate policer[1], and then later discussing hysteresis[2][3]?  Even
> so, the draft suggests that looking at which flows are filling up the queue
> is a better approach.
>
>
>
> [1]
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-6
>
> [2]
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-7
>
> [3]
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-23.html#section-5.2-8
>

[MD] I withdraw the comment.


>
>
> Nits:
>
>
>
> (1) "A node supporting the NQB PHB makes no guarantees on latency"
>
>
>
> Doesn't the size of the queue provide an upper bound on latency?
>
>
>
> [GW] I suppose that it does in some cases.  A simple fix would be to
> delete the first phrase of that sentence (up to the comma). Is that what
> you’d like to see?
>

[MD] I might just add the qualification "beyond the size of the queue", but
I'm happy to accept whatever you decide to do.


>
>
> (4.1) Is the number of bytes sent counted at the IP layer (i.e it counts
> the IP header and all layers above it?)
>
>
>
> [GW] Yes, that was the intent.  Would changing it to “number of IP bytes
> sent” work for you?
>

[MD] definitely.


>
>
> Martin
>
>
>
>
>