Re: [Apn] Drafts vs. presentation

[Adrian Farrel <[e-mail]>]

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?

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

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

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.

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

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).

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

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

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

"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