Re: [Apn] Problem statement

Ted Hardie <ted.ietf@gmail.com> Wed, 17 May 2023 13:45 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B95C1519BF for <apn@ietfa.amsl.com>; Wed, 17 May 2023 06:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGorIUMngakK for <apn@ietfa.amsl.com>; Wed, 17 May 2023 06:44:58 -0700 (PDT)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714CEC1519B4 for <apn@ietf.org>; Wed, 17 May 2023 06:44:58 -0700 (PDT)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-965a68abfd4so135924166b.2 for <apn@ietf.org>; Wed, 17 May 2023 06:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684331096; x=1686923096; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=68twSmdRVJBWtu4TQOLzV1r5IVa4NYY/s0/wS4RuCqY=; b=caM/jMBKKccx9GDZoki+yKuIg1h9uHC79xbEs51/tpDDCY5x8sOXXXIROdwh0h1qnT xRI5qwJP3vB8sOA3cJVmyDD2cWFK6pcgltnRtU0FXdwQleDxptfyjvwHWFYN34NRLk/L 8cItf43rQldBzDiV6XuegsLyZ8TM5colawY2J4c21wL0K1y3ORtdSolyi+G3OeRx57j6 /ngemLt66cm+vSXDUonom2TlbPCJB58vwgOHhvZsQdh/prhZ+2FaHiFrlbiCfV2Rfgp8 pkFfhz/uoI0q4HtemsH8TTMpT9mXtouX868ilQQbMJ566J0Gw+ShxUTzdOFgh41mELTA 6U3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684331096; x=1686923096; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=68twSmdRVJBWtu4TQOLzV1r5IVa4NYY/s0/wS4RuCqY=; b=ZI7/Uie5D6LE79QFBUEI3NWoSzFhPJNnwVmlYiru4FSC5Mo6XR/0IWgzDstw5BDyYO 1f2Wta5LfLWcg5gddNHqwJjz9EHnMxawWavBLN1yjYdlxgMLb2AE7mt4svECEpnLss6d z75RmUBPl690IdyjLWozDynVNvnZY1M6FHkzRVnLCiwVZN3wlN/6RWAxY2WPlXhSDtav v+wSYNuqKBwfS/AWKEop8GT8vHfHeuq2dwB8U5YGSx7EiaIwmYBK1fYRLScj0fsrZU1I IQa6rHtZpowboeJVj0sMAbNvWJrn1oR3OQ7JxonE8Omvea9lJGKAkiOg9cfYi+q/yO2G r6xQ==
X-Gm-Message-State: AC+VfDyW86TR21uexAHbSMwni6cCOwkuE2OhtDAOnqiwrc41xB2EgRni bKXOY61GWj7bu8PLz7KlWfdx55ak64QaeZUjuBgh/q10OShHPQ==
X-Google-Smtp-Source: ACHHUZ6tHR4GgXQ351Lg2WHshNVWnMeryUkYkQm1AX0LTT0MAu6Z2Csrv8/mxZwEUvSp0e3giXgsiWwJqN8jc1Rjj/U=
X-Received: by 2002:a17:907:724d:b0:96a:53e6:eab5 with SMTP id ds13-20020a170907724d00b0096a53e6eab5mr20634556ejc.41.1684331095919; Wed, 17 May 2023 06:44:55 -0700 (PDT)
MIME-Version: 1.0
References: <484bb9971aff4810ae45a756e849420a@huawei.com> <CA+9kkMD7HxsoFemfAjYhJHNsp3RNn3-TeDvewpnMHQy+1bHZGw@mail.gmail.com> <025101d97eb7$4ef7fc10$ece7f430$@olddog.co.uk> <4c31fbbd69724a72952bbd563c22697e@huawei.com>
In-Reply-To: <4c31fbbd69724a72952bbd563c22697e@huawei.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 17 May 2023 14:44:29 +0100
Message-ID: <CA+9kkMBjaHaie91fRtXdujLZii6suFR3qauZHcWrJ0XT-nYwCg@mail.gmail.com>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "apn@ietf.org" <apn@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a80ff905fbe3e416"
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/bd6sIA-maqO6Cgl5BKoocKkWJBE>
Subject: Re: [Apn] Problem statement
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 May 2023 13:45:00 -0000

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) <
pengshuping@huawei.com> 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.



> 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?


> 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, and generic enough information is needed to
> determine these treatments in 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?

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?



> 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




>
>
>
>
> *From:* Adrian Farrel [mailto:adrian@olddog.co.uk]
> *Sent:* Friday, May 5, 2023 2:36 AM
> *To:* 'Ted Hardie' <ted.ietf@gmail.com>; Pengshuping (Peng Shuping) <
> pengshuping@huawei.com>
> *Cc:* apn@ietf.org
> *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
> Apn@ietf.org
> https://www.ietf.org/mailman/listinfo/apn
>
>