Subject: [Network-tokens] Questions for APN: Q#6 and Q#7

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Sun, 27 Sep 2020 13:26:52 +0000

Dear all,

#6. Is the fine-granularity operation needed/desired in the network?
Answers: 5G enables various demanding applications that desire high reliability and ultra-low latency requirements. These demanding applications or mission-critical applications desire to be differentiated and treated specially. However, in the current network with the existing mechanisms, these fine-granularity requirements cannot be fulfilled.

#7. Why not just use DSCP?
Answers: DSCP is only a few bits and not sufficient for indicating the various applications and their different requirements. It needs much richer expressions than the DSCP. Moreover, DSCP can be remarked at the network edge.

Best regards,
Shuping

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: [email-masked]
Cc: Pengshuping (Peng Shuping) <[email-masked]>
Subject: Question List for APN

Hi Folks,
Thanks very much for your attention to APN work. After much preparation work, we summarized the key questions to be clarified for APN which also were always asked. In fact in the past discussion and the APN side meeting of IETF108, many of these questions were discussed and clarified. Here we propose these questions together for your convenience.

The questions to be clarified are as follows:
#1. Which layer is for APN to do the application-aware work?
#2. Does APN provide services within a limited-domain or Internet?
#3. Which area in IETF would the APN work fit better?
#4. What is the relationship between APN and other attempts in IETF’s history?
#5. What are the valuable use cases/usage scenarios of APN?
#6. Is the fine-granularity operations needed/desired in the network?
#7. Why not just use DSCP?
#8. Does APN violate network neutrality?
#9. Will APN raise security issues since application-aware information is carried in the APN packets?
#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?

Shuping Peng will send the detailed answers for these questions in the mailing list in the following one or two weeks. The questions and answers may be not only be sent in the APN mailing list, but also be copied to the architecture discussion mailing list and the network token mailing list for more cross-area feedback if necessary.

If you have any comments on these questions and answers, we can go on to discuss through the mailing list.

Best Regards,
Zhenbin (Robin)

From: Apn [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Apn] Welcome to APN Mailing List

Hi Folks,

Welcome to join the APN mailing list. We are glad to have more discussion through the mailing list as the follow-up of the IETF108 APN side meeting.
In the process of APN work, many historic work items such as SPUD, PLUS, etc. have been proposed. It has been tried to be clarified that APN focuses
on the network layer and limited domains. Concerns on the security and privacy issues also have been proposed many times about the work. It also
has been tried to be clarified that in the trustable limited domains the security and privacy issues can be under control. These are the reasons why APN
work is based in the RTG area instead of ART/TSV areas.

But because of too much historic work to be clarified and its proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF are involved, it is
necessary to have more discussion to clarify the scope and work items for APN. We wish the mailing list would be helpful to the work and promoting the
cross-area communication to understand each other better.

You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/>, especially the materials
From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN>. This link also gives you pointers to
some of the relevant Internet-Drafts.

Over the next few weeks we will try to guide discussion by introducing some questions for debate. But please also raise your own issues and concerns
and contribute to the exchanges on this list.

Look forwarding to have more fun discussion in the mailing list.

Best Regards,
Dan & Zhenbin

---

From: [email-masked]
Date: Sun, 27 Sep 2020 10:17:11 -0700

Hi Shuping,

Just how many bits are we talking then? And where are they in the packet?

Tony

> On Sep 27, 2020, at 6:26 AM, Pengshuping (Peng Shuping) <[email-masked]> wrote:
> 
> Dear all,
>  
> To: [email-masked] <mailto:[email-masked]>
> Cc: Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>>
>  <> 
> From: Apn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lizhenbin
> To: [email-masked] <mailto:[email-masked]>
> You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/ <https://github.com/APN-Community/>>, especially the materials
> From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN <https://github.com/APN-Community/IETF108-Side-Meeting-APN>>. This link also gives you pointers to
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 29 Sep 2020 01:30:48 +0000

Hi Tony,

Please refer to the following drafts. Some related descriptions can be found in these drafts.
https://tools.ietf.org/html/draft-li-apn-framework-01#section-5
https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02

Basically, the information carried in the IP layer is used for traffic steering policy selection within a limited APN network domain in order to guarantee the SLA requirements.

Best regards,
Shuping

From: Network-tokens [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 28, 2020 1:17 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7

Hi Shuping,

Tony

On Sep 27, 2020, at 6:26 AM, Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Best regards,
Shuping

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>
Subject: Question List for APN

Hi Folks,

Best Regards,
Zhenbin (Robin)

Hi Folks,

Best Regards,
Dan & Zhenbin

_______________________________________________
Architecture-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: [email-masked]
Date: Tue, 29 Sep 2020 14:31:38 -0700

Hi Shuping,

> https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02 <https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02>
>  

I’m a little unclear on what I’m reading, so please pardon some clarifying questions.

In this document, I’m seeing two options defined for use in IPv6 extension headers.

The application aware ID option appears to be up to 255 bytes long, variable length, and consists of three different structures.

How does the forwarding engine determine which structure is in use? Can this option appear multiple times in the header? 
Within each structure, the fields are variable length, but there appears to be no way to determine how long the fields are.

The service-para option appears to be a bit more structured.  Again, this appears to be variable length, up to 255 bytes.
Within the option, we have numerous subTLVs. What is the purpose of the RESERVED fields? If you’re trying to retain alignment,
didn’t that go out the window with a two byte option header?

Does the delay sub-TLV indicate the overall path delay? Or the per-hop delay?  If the full path delay, how does a router know
whether this has been satisfied?  Do systems along the path decrease this value as the packet is forwarded? How does a router
know how much to decrement?

Is 24 bits really necessary for the Delay Variation?  Is a jitter of 16s even meaningful?

The packet loss ratio is a 24 bit (presumably unsigned) value.  Is this an integer? Normally ratios are expressed as a relation between multiple
integers. What are the semantics here?

Have you computed the amount of overhead that you will be introducing? It appears to me that you could easily have 1000 bytes of overhead per packet.  What does 
this do to service provider bandwidth consumption? What does this do to the ‘low-latency’ service that you want to provide?

Tony