Subject: [Apn] Drafts vs. presentation

From: Watson Ladd <[email-masked]>
Date: Fri, 19 Mar 2021 23:39:03 -0700

Dear all,

I must confess that the SAAG presentation on APN was at a time of day
when I am ordinarily asleep and my caffeine titre might not have been
as high as necessary. But what I recall in that presentation and the
framework draft seem to be at odds, and I have some rather basic
questions about this.

Firstly, it sounded like the service indications need to be parsed at
very high rate, enabling cut-through. But the drafts have variable
length TLVs with a wide variety of options, which to me would be
incompatible with this sort of processing. It seems that the same
option can carry user ids and application ids, as well as very
detailed information about desired service levels, beyond what I think
network operators could reasonably make use of. Wouldn't it be simpler
to have named classes and have a fixed 16 bit field to select this
class? or pad it out to whatever is needed for aligment beyond it. 65k
classes is enough for anybody.

Secondly the framework draft seems to want to be independent of the
underlying transport, be it MPLS, IP, etc. And I don't think that
really is necessary In my limited understanding, the sort of decision
an MPLS path element makes is extraordinarily limited: the network is
a stack machine: you pop the label, plop on a few labels, off it goes.
All the intelligence is at the entrance and exits, and there isn't
really a local view of what path is better for what policy: whole idea
of MPLS is to avoid that.

I think the proponents of this need to state the goal, and have drafts
that achieve that goal, and communicate it clearly. Otherwise I feel
like I'm grappling with a rather protean set of drafts, one that
promises all things to all people in ways that don't move the
conversation forward.

Sincerely,
Watson Ladd
-- 
Astra mortemque praestare gradatim

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 20 Mar 2021 09:50:38 -0000

Hi Watson,

Some really good points here (thoughts in line) to which I would also add
the observation that there was confusion in the meeting between the slides
clear statements and what people believed they had read in the drafts
(especially the framework). This covered:
- Is the application/user identified to the network by the APN ID?
- Who is responsible for placing the APN ID in the packets?
If the slides were right then I am much less worried by APN. Possibly some
cleaning of words is needed in the drafts?

> very high rate, enabling cut-through.

I'd agree with this. I think APN is about making forwarding decisions and/or
packet handling decisions at line rate.

> But the drafts have variable length TLVs with a wide variety of options, 
> which to me would be incompatible with this sort of processing.

I think there are two points here:
1. We should separate the framework and requirements from the proposed
solutions.
Just because we don't like some of the details of the proposed solution is
not a reason to throw out the concept.
This is a bit of a Catch-22 [1] for people introducing work to the IETF:
either they get accused of trying to have their idea rubber-stamped [2], or
they are told that they haven't provided enough details of how the solution
will work. Hopefully we can work out whether the function is desirable and
then (if it is) work out a solution through the "normal" IETF discussion
process.

> It seems that the same option can carry user ids and application ids, as 
> well as very detailed information about desired service levels, beyond
> what I think network operators could reasonably make use of.

This is the line of worry for me. If user ids and application ids *can* be
carried, it is easy to make the argument that applications and users that
are worried about privacy are not required to supply the information.
However, it seems to me that applications do not have a good history of
caring about users' privacy, while users do not always have control over
what an application puts in a packet.

> Wouldn't it be simpler

This would, indeed, be simpler. But I think it gets complicated to get the
relative gradations of different aspects of "quality". Consider that there
might be five aspects of service delivery that the application wishes to
request (throughput, delay, latency, jitter, and fud). Give each one a range
of 0-100. Now you have a lot of classes. (In practice, of course, 100 might
be reduced to 15, but 5 might increase to 20).

Perhaps, therefore, it is better to consider having a number of fields and
let the network tell the application how to use those fields to indicate
different things.

> a stack machine: you pop the label, plop on a few labels, off it goes.

Not so, I fear.

MPLS supports ECMP. That involves hashing the label stack and beyond. The
"entropy label" was introduced for implementations that can't see far enough
into the packet to reach the payload 5-tuple.

MPLS also has three Traffic Class bits for providing varied per-hop
behaviors.

Furthermore, some suggestions have been made for carrying additional
forwarding guidance in the MPLS label stack. For example, a label can
indicate a forwarding function to be applied to the next label in the stack.
(The most simple form of this is "pop-and-go" or VRF indicator).

> that achieve that goal, and communicate it clearly. 

Couldn't agree more. I believe the framework draft does contain this goal,
but it still needs clarification.

> Otherwise I feel

"Protean" may be unfair. But more focus is clearly needed to help the
readers understand what the proponents want.
 
> Astra mortemque praestare gradatim

Benefactores servant futurum

Best,
Adrian

[1] https://en.wikipedia.org/wiki/Catch-22
[2]
https://www.modernprint.co.uk/wp-content/uploads/2018/02/Traditional_rubber_
stamp_makers_in_Pembrokeshire.jpg

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 22 Mar 2021 09:29:35 +0000

Hi Watson, Adrian, 

Thank you for your comments and feedback! Please find some responses in line below, starting with "Shuping". 

-----Original Message-----
From: Apn [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Saturday, March 20, 2021 5:51 PM
To: 'Watson Ladd' <[email-masked]>; [email-masked]
Subject: Re: [Apn] Drafts vs. presentation

Hi Watson,

Some really good points here (thoughts in line) to which I would also add the observation that there was confusion in the meeting between the slides clear statements and what people believed they had read in the drafts (especially the framework). This covered:
- Is the application/user identified to the network by the APN ID?
- Who is responsible for placing the APN ID in the packets?
If the slides were right then I am much less worried by APN. Possibly some cleaning of words is needed in the drafts?

Shuping> Please refer to the slides we presented in this IETF as well as this draft https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-01 which contains the latest introduction of APN. Some existing drafts still include both host-side solution and network-side solution, but now we only focus on the network-side solution, which uses the network edge devices to tag the APN attribute rather than the applications. APN is not about identifying the particular user or application. APN is about efficiently enforcing policies within the network to a particular flow that can be differentiated with the existing fields in the packet header. 

> very high rate, enabling cut-through.

I'd agree with this. I think APN is about making forwarding decisions and/or packet handling decisions at line rate.

> But the drafts have variable length TLVs with a wide variety of 
> options, which to me would be incompatible with this sort of processing.

I think there are two points here:
1. We should separate the framework and requirements from the proposed solutions.
Just because we don't like some of the details of the proposed solution is not a reason to throw out the concept.
This is a bit of a Catch-22 [1] for people introducing work to the IETF:
either they get accused of trying to have their idea rubber-stamped [2], or they are told that they haven't provided enough details of how the solution will work. Hopefully we can work out whether the function is desirable and then (if it is) work out a solution through the "normal" IETF discussion process.

Shuping> Well said, Adrian. Yes, we would like to explore the reasonable solutions together with the community. 

> It seems that the same option can carry user ids and application ids, 
> as well as very detailed information about desired service levels, 
> beyond what I think network operators could reasonably make use of.

This is the line of worry for me. If user ids and application ids *can* be carried, it is easy to make the argument that applications and users that are worried about privacy are not required to supply the information.
However, it seems to me that applications do not have a good history of caring about users' privacy, while users do not always have control over what an application puts in a packet.

Shuping> APN is not about identifying the particular user or application. The network does not need to know this kind of information which may infringe the privacy, and it will not be useful to the network either. The network will only need an opaque value or a bit string to enforce the policies. 

> classes is enough for anybody.

This would, indeed, be simpler. But I think it gets complicated to get the relative gradations of different aspects of "quality". Consider that there might be five aspects of service delivery that the application wishes to request (throughput, delay, latency, jitter, and fud). Give each one a range of 0-100. Now you have a lot of classes. (In practice, of course, 100 might be reduced to 15, but 5 might increase to 20).

Perhaps, therefore, it is better to consider having a number of fields and let the network tell the application how to use those fields to indicate different things.

Not so, I fear.

MPLS supports ECMP. That involves hashing the label stack and beyond. The "entropy label" was introduced for implementations that can't see far enough into the packet to reach the payload 5-tuple.

MPLS also has three Traffic Class bits for providing varied per-hop behaviors.

Furthermore, some suggestions have been made for carrying additional forwarding guidance in the MPLS label stack. For example, a label can indicate a forwarding function to be applied to the next label in the stack.
(The most simple form of this is "pop-and-go" or VRF indicator).

> that achieve that goal, and communicate it clearly.

Couldn't agree more. I believe the framework draft does contain this goal, but it still needs clarification.

Shuping> Thank you for your suggestions! We will refine the draft accordingly.

> promises all things to all people in ways that don't move the 

"Protean" may be unfair. But more focus is clearly needed to help the readers understand what the proponents want.

Shuping> Agree. For now, please refer to this draft https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-01 and the slides presented in this IETF. Thank you! 

Best regards, 
Shuping 

Best,
Adrian

--
Apn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apn