Re: [Apn] Problem statement

[Joel Halpern <[e-mail]>]

Source routing is often controller driven because the controller can see 
the multiple sources of traffic who may content for a path.  If one is 
not worried about resource competition, but only about path selection, 
then the ingress router can use local policy to apply source routing and 
/ or selection of flex-algo based tunnel end-point identification to 
perform the needed control. Note that flex-algo can be dombine with DSCP 
or the QoS markings for MPLS to enable queueing differentiation along 
with path selection.

I expect that NRP usage will be controller driven as it is usually 
assumed to be tied to resource maangement across multiple traffic 
sources.  But again, if one has looser needs then they can probably be 
met in a more distributed fashion.

Yours,

Joel

On 5/23/2023 10:07 AM, Mohammed Umair wrote:
> Hi Joel,
>
> In the first point, ignore QoS for noe, the source routing that you 
> mentioned requires controller if I am not wrong (correct me if I am 
> missing something here), so this controller dependency is always be 
> there, if we can include this info of Latency on the new header, we 
> can avoid the dependency on controller, regarding the queueing part, I 
> don't think, queueing will provide any info on the which 
> port/interface of a device is having lower latency, this requires the 
> tolls like performance measurement, I will discuss the Flex-Algo in 
> the next point.
>
> In the second point, Yes Flex-Algo is there and I agree, but when 
> someone requires the different treatment of the packet within that 
> Algo, then how to consider that?
>
> Agree with you on the third point.
>
> Regards,
> Umair
>
>
>
> On Tue, May 23, 2023 at 7:12 PM Joel Halpern <[e-mail]> wrote:
>
>     I am not sure I understand your points.
>
>     Your scenario 1 says that the two VPNs have the same "set of QoS
>     values" but then says that one should use low latency and one
>     should avoid low latency.  (Note that "avoid low latency" is
>     probably not meaningful.)  latency is a QoS parameter.  So the two
>     VPNs do not have the saem "set of QoS Values".  They don't even
>     have the same set of queueing parameters since queueing treatment
>     is an important part of achieving low latency.  As for path
>     selection, we have both source routing and flex-algo as tools to
>     achieve differentiated path selection.
>
>     Your second scenario says that operators using IGP always use the
>     default metric.  This is not the case.  The IGPs advertise
>     additional metrics which can be used with soruce routing (MPLS or
>     SRv6) to achieve suitable path selection.  Further, one can us
>     Flex-Algo (with IPv6, MPLS, or SRv6) to have even better control
>     over the path selection algorithm.
>
>     Your third scenario talks about differing discard priorities. 
>     DSCP alreayd supports this at a coarse level with three different
>     AF classes.  It can support significantly more nuanced drop
>     priorities as there are a good number of code points for IP DSCP
>     (there are fewer with SR-MPLS; that is being addressed).  Further,
>     the NRP structures from TEAS allow even more detailed control over
>     traffic treatment, and the community will determine what markings
>     are needed for that.  We do not need a new working group for it.
>
>     Yours,
>
>     Joel
>
>     On 5/23/2023 9:14 AM, Mohammed Umair wrote:
>>     Hi,
>>
>>     Apologies for my late entry into this discussion.
>>
>>     In my opinion the operators domain faces most of the problem is
>>     not with the QoS but rather in the treatment of a packet in it's
>>     network.
>>     I have tried to capture a few of the scenarios/points below.
>>
>>
>>     Scenario 1 : latency dependent application/traffic.
>>     ==========================================
>>     VPN-A and VPN-B both when traversing the network have traffic
>>     with same set of QoS values to the same Destination, but VPN-A
>>     should always has to be steered on low latency network, and VPN-B
>>     can take the path other than low latency, so basically we can
>>     think of using the Fine Grained values which are carried directly
>>     into the packet takes the decision Hop by Hop using the
>>     Performance measurement data or end-to-end performance
>>     measurement Data.
>>
>>
>>     Scenario 2:  Network operators who use IGP.
>>     =====================================================
>>     In these networks IGP Metric always gets considered for steering
>>     of the traffic, so there is a need for few packets to take the
>>     metric other than the IGP as well.
>>     These values can be added at the ingress/source of the network
>>     and can also be modified in the middle of the network as well,
>>     something like remarking of QoS Values.
>>
>>
>>
>>     Scenario 3: Treatment of traffic in Congestion.
>>     ====================================================
>>     When a middle device receives two different VPN'S traffic with
>>     same QoS values, Device should have the capability to understand
>>     which traffic needs to be dropped, but since the QoS values are
>>     same sometimes the drop happens randomly in the congested network
>>     (there are few techniques, where using SIP/DIP someone can steer
>>     the traffic to different queues, but sometimes becomes complex),
>>     by using current QoS values and Values in the New header device
>>     can take the decisions.
>>
>>
>>     Regards,
>>     Umair
>>
>>
>>     On Sat, May 20, 2023 at 8:16 AM Joel Halpern
>>     <[e-mail]> wrote:
>>
>>         As Jim likes to point out to me, SFC can steer to whatever
>>         you want.  So I think it is important to specify what problem
>>         we have that SFC does not address.  Targeting specific queues
>>         on specific nodes is clearly within SFC.  Targeting specific
>>         classes of service across all nodes is DSCP.
>>
>>         Yours,
>>
>>         Joel
>>
>>         On 5/19/2023 7:28 PM, Pengshuping (Peng Shuping) wrote:
>>>
>>>         Hi,
>>>
>>>         I agree with your capture, that is, it is more like a
>>>         SFC-like approach. The current SFC is the chain of service
>>>         functions, but here we want to do more than just service
>>>         functions. Actually both underlay and overlay network
>>>         elements are involved, including network nodes and service
>>>         functions.
>>>
>>>         Regarding particular uses, I am thinking whether we could
>>>         categorize them into several types, for example,
>>>
>>>         1.Steering: into queues of nodes, or paths going through
>>>         nodes and service functions, or virtual instance on each
>>>         service function
>>>
>>>         2.Triggering: certain services such as various performance
>>>         measurement mechanisms
>>>
>>>         3.Identifying: the packets belonging to which traffic groups
>>>         in the middle of the network, i.e. VPN, sites, access
>>>         interfaces, to enforce group-level policies efficiently
>>>
>>>         Please find more responses in line. Thank you!
>>>
>>>         *From:*Ted Hardie [mailto:[e-mail]
>>>         <mailto:[e-mail]>]
>>>         *Sent:* Wednesday, May 17, 2023 9:44 PM
>>>         *To:* Pengshuping (Peng Shuping) <[e-mail]>
>>>         <mailto:[e-mail]>
>>>         *Cc:* [e-mail]; [e-mail]
>>>         *Subject:* Re: [Apn] Problem statement
>>>
>>>         My apologies for taking so long to reply; I started a reply
>>>         and lost track after I  put it aside.
>>>
>>>         Some comments in-line.
>>>
>>>         On Sat, May 6, 2023 at 11:25 AM Pengshuping (Peng Shuping)
>>>         <[e-mail]> wrote:
>>>
>>>             Hi,
>>>
>>>             These are very good points and suggestions. Thank you!
>>>
>>>             I try to first summarize the current discussions, which
>>>             actually lead to three key questions that need to be
>>>             answered.
>>>
>>>             1.What are the core problem?
>>>
>>>             2.What are the uses?
>>>
>>>             3.What are the key items?
>>>
>>>         I think this is missing a critical question:  what is it
>>>         about this set of uses that makes an omnibus solution the
>>>         right approach?  Unless I have missed something basic, this
>>>         appears to encompass a fairly broad swath of potential use
>>>         cases, some of which already have well-established alternate
>>>         approaches outside the data plane.  Some description of why
>>>         these signals belong together is necessary, unless you are
>>>         suggesting that the eventual scope will be a single use case.
>>>
>>>         Shuping> The thing is that we would need to somehow keep the
>>>         description more abstract. Considering the uses people have
>>>         explained so far in the mailing list and previous
>>>         discussions. Whether it would be good if we could categorize
>>>         the uses into types, as I listed before: steering,
>>>         triggering, identifying, …
>>>
>>>             Let’s focus on them one by one.
>>>
>>>             1.What are the core problem?
>>>
>>>             Maybe we could first try to use one sentence to describe
>>>             this core problem. Considering the discussions, I am
>>>             thinking that this sentence would be something like “How
>>>             to maintain continuously the fine granularity within the
>>>             network in an efficient manner”. Please suggest better
>>>             wording.
>>>
>>>             I like the following paragraph extended by Adrian and
>>>             further add this summary sentence at the end. Your
>>>             comments and suggestions are welcome.
>>>
>>>             “In a network operator controlled domain, the ingress
>>>             edge devices usually have access to rich information,
>>>             such as VLAN/QinQ, VPN ID, and access interface, which
>>>             is used to classify the packets into fine granular
>>>             virtual groups of flows at the edge. However, after the
>>>             packets enter the network operator’s domain, all such
>>>             information is not immediately visible at transit nodes:
>>>             it may be hidden inside encapsulation, masked by
>>>             encryption, mapped to other protocol fields, or stripped
>>>             from the packets completely. Furthermore, many mapping
>>>             schemes, where they are used, lose some level of
>>>             granularity from the information available at the
>>>             network edge. For example, when the information is
>>>             mapped into small fields like DSCP (6 bits) or MPLS EXP
>>>             (3 bits) the result is that only relatively coarse
>>>             grained QoS treatment can be provided. How to maintain
>>>             continuously the fine granularity within the network in
>>>             an efficient manner is the core problem to focus upon. ”
>>>
>>>             2.What are the uses?
>>>
>>>             I fully agree with both of you on making the uses clear.
>>>
>>>             First of all, I need to clarify that “to affect queuing
>>>             behaviours”is not my main focus. Queuing is at the node
>>>             level, but I look more at the network level, like
>>>             traffic steering along appropriate paths or slices. On
>>>             the contrary, this sentence of Adrian is in my scope,
>>>             “this information might be used to supplement routing
>>>             information and help send traffic from different flows
>>>             onto different paths according to the capabilities of
>>>             the network and the demands of the traffic”
>>>
>>>         How fine grained will this actually be?  It cannot
>>>         realistically be more fine grained than the number of paths
>>>         with differing capabilities.  That's why there has been an
>>>         aggregation step in production networks for a long time. If
>>>         the boxes along the path don't have the ability to queue
>>>         these differently, this ends up being more like service
>>>         function chaining than differential network capabilities, right?
>>>
>>>         Shuping> “Fine” may be a bit misleading? “Flexible” might be
>>>         a good word? I found that when we talk about “Fine”, people
>>>         will relate it immediately with QoS. We are actually
>>>         targeting more uses than QoS. Even for QoS, the actual case
>>>         is that the nodes have much high capability, not only a few
>>>         queues, just this capability is not fully utilized yet.
>>>         Something needs to be done here to change this status.
>>>
>>>         Shuping> It is indeed more like a SFC-like approach, just
>>>         not only including SF. Thank you!
>>>
>>>             Basically, as we listed before, “to apply various
>>>             policies in different nodes along a network path onto a
>>>             traffic flow altogether, for example, at the headend to
>>>             steer into corresponding path, at the midpoint to
>>>             collect corresponding performance measurement data, and
>>>             at the service function to execute particular policies.
>>>             Currently there is still no way to efficiently realize
>>>             this composite network service provisioning along the path.”
>>>
>>>             Therefore, I further extend this sentence as the
>>>             followings. Please let me know how you think.
>>>
>>>             “The packet treatments needed may vary at different
>>>             parts of the packet’s path within the domain, andgeneric
>>>             enough information is needed to determine these
>>>             treatmentsin an efficient and unified way. Thus, the
>>>             continuous fine grained network services within the
>>>             network domain cannot be provided efficiently.  For
>>>             example, at the headend to steer into corresponding
>>>             path, at the midpoint to collect corresponding
>>>             performance measurement data, and at the service
>>>             function to execute particular policies. Currently there
>>>             is still no way to efficiently realize this composite
>>>             network service provisioning along the path.
>>>
>>>         Does packet treatment always mean steer, or does it have
>>>         other meanings?
>>>
>>>         Shuping> Steering, triggering, identifying… what I have
>>>         summarized above, please suggest more or revisions.
>>>
>>>
>>>         I'm also afraid that "Currently there is still no way to
>>>         efficiently realize this composite network service
>>>         provisioning along the path" falls into a fairly common
>>>         charter trap: presuming that the new thing is better than
>>>         the existing thing before you have built it and assessed the
>>>         trade-offs.
>>>
>>>             This information can be carried directly in the packet
>>>             or achieved through a mapping from an opaque tag.
>>>             Existing protocols such as SFC/NSH, SR/SRv6, MPLS,
>>>             VXLAN, and IPv6, can be taken as implementation basis,
>>>             but in each case the protocol may need extensions.”
>>>
>>>         Could I ask for an example of what extension MPLS might need
>>>         to accomplish this traffic engineering?  Or did you have a
>>>         different packet treatment in mind?
>>>
>>>         Shuping> The required MPLS extensions are up to the MPLS
>>>         folks to explore. Currently there are on-going activities in
>>>         IETF. The work here was also considered as one of their use
>>>         cases.
>>>
>>>             3.What are the key items?
>>>
>>>             Yes, considerations on privacy and security need to be
>>>             taken as the key work items. We will need to specify the
>>>             potential privacy and security aspects, mitigation
>>>             mechanisms, and principles with particular emphasis on
>>>             reducing the exposure of confidential/private
>>>             information outside the network.
>>>
>>>             Please also suggest other work items.
>>>
>>>             Best Regards,
>>>
>>>             Shuping
>>>
>>>         Sorry again for the long delay in replies.
>>>
>>>         Ted
>>>
>>>         Thank you!
>>>
>>>         Best Regards,
>>>
>>>         Shuping
>>>
>>>             *From:*Adrian Farrel [mailto:[e-mail]]
>>>             *Sent:* Friday, May 5, 2023 2:36 AM
>>>             *To:* 'Ted Hardie' <[e-mail]>; Pengshuping
>>>             (Peng Shuping) <[e-mail]>
>>>             *Cc:* [e-mail]
>>>             *Subject:* RE: [Apn] Problem statement
>>>
>>>             Hi all,
>>>
>>>             Reasonable points, Ted.
>>>
>>>                 In a network operator controlled domain, the ingress
>>>                 edge devices usually have access to much richer
>>>                 information, such as VLAN/QinQ, VPN, and access
>>>                 interface, which is used to classify the packets
>>>                 into fine granular virtual groups of flows at the
>>>                 edge. However, after the packets enter the network
>>>                 operator’s domain, all such information is lost
>>>                 together with the continuous fine granularity within
>>>                 the network.
>>>
>>>             "all such information is lost together with the
>>>             continuous fine granularity within the network" seems to
>>>             be the core of the problem statement.  I think it is not
>>>             quite correct as stated, in that the information is not
>>>             lost; it is distributed. Because this is within a single
>>>             operator's domain, the operator can construct the
>>>             network to map data like VLAN to specific address
>>>             announcements or DHCP assignments; even if there is a
>>>             later NAT or CGNAT, the operator should control all of
>>>             the devices which implement those mappings.  That means
>>>             the operator has (or can have) this information now;
>>>             it's just distributed through the network.
>>>
>>>             I think you need to be clear about this because it makes
>>>             it more obvious that you are describing a potential
>>>             optimization, rather than truly new functionality.
>>>
>>>             In a network operator controlled domain, the ingress
>>>             edge devices usually have access to much richer
>>>             information, such as VLAN/QinQ, VPN, and access
>>>             interface, which is used to classify the packets into
>>>             fine granular virtual groups of flows at the edge.
>>>             However, after the packets enter the network operator’s
>>>             domain, all such information is lost together with the
>>>             continuous fine granularity within the network. But
>>>             maybe we should avoid trying to solve the problem
>>>             statement and just focus on clarifying it.
>>>
>>>             But, anyway, you’re right that “lost” is the wrong word.
>>>             Rather than “lost” we might have “not immediately
>>>             visible”. But perhaps a few more words would help draw
>>>             out this fundamental part of the problem statement and
>>>             make clear the potential limitations of existing
>>>             approaches (which leads on to the comment about “fine
>>>             grained information”). So, perhaps…
>>>
>>>             In a network operator controlled domain, the ingress
>>>             edge devices usually have access to rich information,
>>>             such as VLAN/QinQ, VPN ID, and access interface, which
>>>             is used to classify the packets into fine granular
>>>             virtual groups of flows at the edge. However, after the
>>>             packets enter the network operator’s domain, all such
>>>             information is not immediately visible at transit nodes:
>>>             it may be hidden inside encapsulation, masked by
>>>             encryption, mapped to other protocol fields, or stripped
>>>             from the packets completely. Furthermore, many mapping
>>>             schemes, where they are used, lose some level of
>>>             granularity from the information available at the
>>>             network edge. For example, when the information is
>>>             mapped into small fields like DSCP (6 bits) or MPLS EXP
>>>             (3 bits) the result is that only relatively coarse
>>>             grained QoS treatment can be provided.
>>>
>>>             The packet treatments needed may vary at different parts
>>>             of the packet’s path within the domain, and enough
>>>             information is needed to determine these treatments.
>>>             Thus, the continuous fine grained network services
>>>             within the network domain cannot be provided
>>>             efficiently. This information can be carried directly in
>>>             the packet or achieved through a mapping from an opaque
>>>             tag. Existing protocols such as SFC/NSH, SR/SRv6, MPLS,
>>>             VXLAN, and IPv6, can be taken as implementation basis,
>>>             but in each case the protocol may need extensions.
>>>
>>>             I also believe that you need to include a statement
>>>             about what the network is going to do with the "fine
>>>             grained information", because you can't judge whether a
>>>             proposal serves the purpose adequately without that.  
>>>             If your aim is to carry it to an orchestrator inside an
>>>             operator network for action (as in the source quench
>>>             example Adrian came up with), then this is a way of
>>>             getting data to that orchestrator rather than using a
>>>             set of database dips.  That has one set of
>>>             characteristics, and my personal guess is that it would
>>>             look much like service function chaining.
>>>
>>>             If your aim is to affect research consumption within the
>>>             network, then you'd both need different data and you
>>>             need the entire network to provide queues at the level
>>>             of granularity that you're proposing. As you point out,
>>>             most things currently get mapped to things like DSCP or
>>>             EXP, and I invite you to consider the tradeoff between
>>>             complex queue management and additional capacity in that
>>>             reality.
>>>
>>>             s/research/resource/
>>>
>>>             I think this is a fundamental point as well.
>>>             Obviously(?) if there is no specific planned use for the
>>>             information, then there is no point in making it available.
>>>
>>>             One of my previous thoughts was that this information
>>>             might be used to supplement routing information and help
>>>             send traffic from different flows onto different paths
>>>             according to the capabilities of the network and the
>>>             demands of the traffic, but I think that this is not in
>>>             scope of Shuping’s proposal.
>>>
>>>             More in scope, from what I understand, is to affect
>>>             queuing behaviours.
>>>
>>>             Now, as you say, “complex queue management” has
>>>             historically been a significant drain on processing and
>>>             hard to manage. There is a claim, however, that newer
>>>             hardware can support very many queues and achieve
>>>             fine-grained and complex scheduling and prioritisation.
>>>
>>>             But the message here is that the text needs to say what
>>>             the purpose of the information is. I do believe that
>>>             this is somewhat covered by the paragraph you quoted
>>>             below (and I folded into my green text, above), but
>>>             maybe it is not clear and clean enough what the use
>>>             cases are. We need to be careful not to invent a tool
>>>             and then look for uses: we need to have clear uses that
>>>             drive the invention of the tool. (Of course, future uses
>>>             may be discovered, and we should try to make the tool as
>>>             generic as possible without losing the benefits of
>>>             specialisation).
>>>
>>>             I also thought there was consensus that this proposal
>>>             needed to have privacy considerations so that the same
>>>             data that carries ingress port information did not carry
>>>             information specific to the user.  While I am sure that
>>>             the proponents are clear on this limitation, I think it
>>>             would be appropriate to repeat that in the problem
>>>             statement text, as that would help new participants
>>>             understand that it is firmly out of scope.
>>>
>>>             I completely agree with this. I think it is very
>>>             important to continue to make this clear because it is
>>>             such a sensitive point for so many people.
>>>
>>>             Best,
>>>
>>>             Adrian
>>>
>>>             best regards,
>>>
>>>             Ted Hardie
>>>
>>>                 Indeed, the information is mapped into small fields
>>>                 like DSCP (6 bits) or MPLS EXP (3 bits). However,
>>>                 such small fields are only able to provide
>>>                 relatively coarse grained QoS treatment. The packet
>>>                 treatments needed may vary at different parts of the
>>>                 packet’s path within the domain, and enough
>>>                 information is needed to determine these treatments.
>>>                 Thus, the continuous fine grained network services
>>>                 within the network domain cannot be provided
>>>                 efficiently. This information can be carried
>>>                 directly in the packet or achieved through a mapping
>>>                 from an opaque tag. Existing protocols such as
>>>                 SFC/NSH, SR/SRv6, MPLS, VXLAN, and IPv6, can be
>>>                 taken as implementation basis, but in each case the
>>>                 protocol may need extensions.
>>>
>>>                 =================
>>>
>>>                 Best Regards,
>>>
>>>                 Shuping
>>>
>>>                 -- 
>>>                 Apn mailing list
>>>                 [e-mail] <mailto:[e-mail]>
>>>                 https://www.ietf.org/mailman/listinfo/apn
>>>                 <https://www.ietf.org/mailman/listinfo/apn>
>>>
>>>
>>         -- 
>>         Apn mailing list
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/apn
>>
>