Subject: [Apn] Fw: Re: [arch-d] Questions for APN: Q#5

From: "[email-masked]" <[email-masked]>
Date: Tue, 22 Sep 2020 14:02:15 +0800

Hi Christian,  Shuping,

  *   Thank you for your comments! Please find my supplementary content in line.

Best regards~
Zhang Shuai

From: Pengshuping (Peng Shuping)<mailto:[email-masked]>
Date: 2020-09-22 09:36
To: Christian Huitema<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Apn] [arch-d] Questions for APN: Q#5
Hi Christian,

Thank you for your comments! Please find my responses in line.
Hope they also address the concerns of John and Joel.

From: Christian Huitema [mailto:[email-masked]]
Sent: Monday, September 21, 2020 2:54 PM
To: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [arch-d] Questions for APN: Q#5

Shuping,

I am reading your use cases, and my immediate reaction is that this developments should not be addressed solely in the routing or IP layers. You are proposing to enrich the network service proposed to transport and applications, which amounts to creating new APIs. Such works affects multiple layers, and should be coordinated between multiple layers.

[Shuping] The APN work to be focused on in the RTG Area is within a controlled limited network domain. To be more specific, when the information indicating application’s requirements is carried within the IP data packet header, APN aims to figure out how the network services can be provisioned according to the carried information, including traffic steering into and along an explicit traffic engineered network path as well as traffic monitoring, etc.. As to where the information is added, it is out of the working scope of the APN in the RTG Area.

Please refer to the first slide in this link which I have presented in APN side meeting @IETF108. It shows a clear scope of the APN work to be conducted in the RTG Area.

https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf

The presentation at the RTG WG @IETF108 can also be found here.

https://github.com/APN-Community/IETF108-RTGWG-APN

I also see that the description of application requirements is very thin. The drafts mention augmented reality and online games, and focus largely on latency requirements for these applications. The latency has two main components: delays in the wires, and queues in the routers. The APN draft for example mentions players of games using servers on another continent, and thus experiencing large latency. But that latency is largely due to the distance. That distance is not going to be magically reduced by smarter queue processing. The same is even more true for video conferencing or telepresence applications. I live near Seattle. If I want to talk to my mother in France, the bits have to be carried across America and the across the Atlantic ocean. No amount of smart routing will change that. Application developers are well aware of these issues, and have designed their applications in consequence.

[Shuping] Between A and B there are usually multiple paths and these paths can possess various characteristics, including delay and reliability, etc. The proper paths can then be selected according to the applications’ requirements and the traffic can be steered into the selected network path/tunnel/policy to guarantee their SLA requirements. To accelerate the latency-sensitive applications such as gaming, acceleration tunnels are usually built, especially for the oversea case because you can see the improvement more clearly. Please find more information in this draft https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00. Operators are actually building such acceleration tunnels themselves.

[Shuai] Indeed, based on our deployment experience, the dedicated game acceleration path is very helpful on improving the QoE of the involved gamers. We look for more collaborations to provide better services to our customers.

There is a lot of tension between Internet Architecture and the "application aware" proposal. The Internet was built on a fundamental decision to not be application aware. Instead, the routers carry packets of bits, independently of which application uses these bits. That way, new applications can constantly be invented, without requiring modifications in the network or permissions from the network operators. This has proven to be key for the development of the Internet. I don't think that we want to change that. Even if we did I don't think that the discussion should take place solely in some specialized routing working groups.

[Shuping] Again APN is aimed to work within a controlled and limited operators’ network domain not for Internet. Within this domain, network operators can provide network services (e.g. traffic steering and monitoring) according to the “application knowledge” carried in the data packets. This knowledge has already been used by most, if not all, operators since the introduction of traffic engineering mechanisms back in 90’s. APN is to automate these mechanisms, which will involve the work on the data plane encapsulations (i.e. IPv6, MPLS, VxLAN, etc.) and routing protocols extensions in the routing working groups.

Best regards,

Shuping

-- Christian Huitema

On 9/20/2020 7:19 PM, Pengshuping (Peng Shuping) wrote:
Dear all,

#5. What are the valuable use cases/usage scenarios of APN?

Drafts have been posted on various use cases such as Game Accelerating, Edge computing, SD-WAN etc.

1)       https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01
2)     https://tools.ietf.org/html/draft-liu-apn-edge-usecase-00
3)     https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase-00
4)     https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase-00

Use cases have also been presented and discussed during the APN side meeting@IETF108. Please find the slides.
https://github.com/APN-Community/IETF108-Side-Meeting-APN

There have been some discussions on these use cases in the APN mailing list as well. Please find the archives.
https://mailarchive.ietf.org/arch/msg/apn/c-fQP4LRpe6yj3lJBsaRxTVcWHA/
https://mailarchive.ietf.org/arch/msg/apn/MCVuBYa7jgtJsIDEpbGTZ0U8Bvg/
https://mailarchive.ietf.org/arch/msg/apn/c-fQP4LRpe6yj3lJBsaRxTVcWHA/

More interesting use cases are waiting to be explored. Please let us know if you have any other use cases. Thank you!

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

_______________________________________________

Architecture-discuss mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/architecture-discuss

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 22 Sep 2020 09:44:45 +0300

Hi,

On 2020-9-22, at 9:02, [email-masked] wrote:
> [Shuping] Again APN is aimed to work within a controlled and limited operators’ network domain not for Internet.

that significantly limits the attractiveness of this proposal to application vendors. They can either buy into APN and ship an app that only works in some (initially, very few to none) operator networks. Or, they can ship a slightly less optimal app that works on the entire Internet with its billions of users.

More broadly, I'd like to point out that during the entire history of the Internet there were application classes that the deployed networks at the time were struggling to support. There were always claims that something like APN was needed, i.e, solutions that were intending to improve network performance and quality but that were also adding significant complexity and often required application changes.

What always happened so far was that Moore's law solved these problems, by improving the performance and quality of the general Internet so that best effort was sufficient to support all these "special" applications a few years down the road.

The same will happen with the use cases presented to motivate the need for APN. The general Internet may struggle to support them now, but in five years or so - which is about the time horizon for any APN enablement of any operator network to happen - these will just work.

Thanks,
Lars

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 Sep 2020 08:29:12 -0700

> More broadly, I'd like to point out that during the entire history of the Internet there were application classes that the deployed networks at the time were struggling to support. There were alway…
Yes indeed. In the 90's the argument was around video conferencing,
which "obviously" could not work on a plain best effort service. And
then we got Skype.
> What always happened so far was that Moore's law solved these problems, by improving the performance and quality of the general Internet so that best effort was sufficient to support all these "spe…
Yes. Indeed the whole history of wireless is driven by Moore's law. For
example, the theory of MIMO has been known for some time, put the
application and the use of large number of input and output is only
possible because of progress in electronics.
> The same will happen with the use cases presented to motivate the need for APN. The general Internet may struggle to support them now, but in five years or so - which is about the time horizon for…

More bandwidth solves a lot of these issues. But we can also expect
improvement in transport protocols and in queue management. Active Queue
Management techniques can isolate different data streams and prevent
stupid issues like "my daughter playing video games is degrading my
VPN". New congestion control protocols like BBR actively manage queuing
delays, resulting in significantly lower latency overall. And then
application just get smarter in their use of caches, redundancy, gap
filling, etc. All that is guaranteed to improve over time.

-- Christian Huitema

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Fri, 25 Sep 2020 23:22:31 +0000

late in the discussion, but wanted to share some thoughts:

One of the first successful proof-points for SDN was Google claiming ( https://cs144.github.io/handouts/cs144_mogul_2019_nov.pdf ) that they moved their WAN utilization to ~100%, instead of over-provisioning. It saved them lots of money. Two of the design principles that led them there were

i) moving from "all packets are equally important" to "allocate resources based on application-level priorities" and

ii) moving from "TCP flows regulated by "fair share" mechanisms" to "measure demands, and shape flows at the endpoints".

I can imagine offering low-latency SLA for 1% of the traffic (say video calls), is much cheaper and easier than doing this for all Internet traffic (with the cost varying whether you are in Europe/US or an emerging market, rural or urban, a WISP, a low-orbit satellite network, etc). *Could anyone from operator-land comment on the economics of oversubscription/overprovision/SLAs in the mobile world?*

(btw: we already have SLAs today --- VoLTE is IP traffic routed through dedicated radio and wired resources and has materially better network quality and reliability than plain VoIP, and when you sign-up for a broadband connection you can get 10Mbps/100Mbps/1Gbps etc).

If over-provisioning wins (in 10 years) it will likely be the outcome of the network community's  failure to find a good solution for traffic differentiation, rather than a verdict that these use cases were not important enough.

FWIW: there are many issues to debate around fine-grained traffic differentiation beyond overprovisioning (like security, scalability, privacy, net neutrality), and there are different approaches one could take (APN and network tokens have different design principles and priorities on these trade-offs).

Best,

Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857

On Tue, Sep 22, 2020 at 8:29 AM, Christian Huitema < [email-masked] > wrote:

>> On 2020-9-22, at 9:02, zhangs366@ chinaunicom. cn (
>> [email-masked] ) wrote:
>> 
>> 
>>> 
>>> 
>>> [Shuping] Again APN is aimed to work within a controlled and limited
>>> operators’ network domain not for Internet.
>>> 
>>> 
>> 
>> 
>> 
>> that significantly limits the attractiveness of this proposal to
>> application vendors. They can either buy into APN and ship an app that
>> only works in some (initially, very few to none) operator networks. Or,
>> they can ship a slightly less optimal app that works on the entire
>> Internet with its billions of users.
>> 
>> 
>> 
>> More broadly, I'd like to point out that during the entire history of the
>> Internet there were application classes that the deployed networks at the
>> time were struggling to support. There were always claims that something
>> like APN was needed, i.e, solutions that were intending to improve network
>> performance and quality but that were also adding significant complexity
>> and often required application changes.
>> 
>> 
> 
> 
> 
> Yes indeed. In the 90's the argument was around video conferencing, which
> "obviously" could not work on a plain best effort service. And then we got
> Skype.
> 
> 
>> 
>> 
>> What always happened so far was that Moore's law solved these problems, by
>> improving the performance and quality of the general Internet so that best
>> effort was sufficient to support all these "special" applications a few
>> years down the road.
>> 
>> 
> 
> 
> 
>> The same will happen with the use cases presented to motivate the need for
>> APN. The general Internet may struggle to support them now, but in five
>> years or so - which is about the time horizon for any APN enablement of
>> any operator network to happen - these will just work.
>> 
>> 
> 
> 
> 
> stupid issues like "my daughter playing video games is degrading my VPN".
> New congestion control protocols like BBR actively manage queuing delays,
> resulting in significantly lower latency overall. And then application
> just get smarter in their use of caches, redundancy, gap filling, etc. All
> that is guaranteed to improve over time.
> 
> 
> 
> -- Christian Huitema
> 
> 
> 
> --
> Network-tokens mailing list
> Network-tokens@ ietf. org ( [email-masked] )
> https:/ / www. ietf. org/ mailman/ listinfo/ network-tokens (
> https://www.ietf.org/mailman/listinfo/network-tokens )
> 
> 
>

---

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

Well said, Yiannis. Thank you!

Best regards,
Shuping

From: Network-tokens [mailto:[email-masked]] On Behalf Of Yiannis Yiakoumis
Sent: Saturday, September 26, 2020 7:23 AM
To: Christian Huitema <[email-masked]>
Cc: [email-masked]; 曹畅 <[email-masked]>; [email-masked]; [email-masked]; apn <[email-masked]>; Lars Eggert <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>
Subject: Re: [Network-tokens] [Apn] [arch-d] Questions for APN: Q#5

One of the first successful proof-points for SDN was Google claiming<https://cs144.github.io/handouts/cs144_mogul_2019_nov.pdf> that they moved their WAN utilization to ~100%, instead of over-provisioning. It saved them lots of money. Two of the design principles that led them there were
i) moving from "all packets are equally important" to "allocate resources based on application-level priorities" and
ii) moving from "TCP flows regulated by "fair share" mechanisms" to "measure demands, and shape flows at the endpoints".

I can imagine offering low-latency SLA for 1% of the traffic (say video calls), is much cheaper and easier than doing this for all Internet traffic (with the cost varying whether you are in Europe/US or an emerging market, rural or urban, a WISP, a low-orbit satellite network, etc). Could anyone from operator-land comment on the economics of oversubscription/overprovision/SLAs in the mobile world?

Best,
Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO

On Tue, Sep 22, 2020 at 8:29 AM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 2020-9-22, at 9:02, [email-masked]<mailto:[email-masked]> wrote:

Yes indeed. In the 90's the argument was around video conferencing, which "obviously" could not work on a plain best effort service. And then we got Skype.

Yes. Indeed the whole history of wireless is driven by Moore's law. For example, the theory of MIMO has been known for some time, put the application and the use of large number of input and output is only possible because of progress in electronics.

More bandwidth solves a lot of these issues. But we can also expect improvement in transport protocols and in queue management. Active Queue Management techniques can isolate different data streams and prevent stupid issues like "my daughter playing video games is degrading my VPN". New congestion control protocols like BBR actively manage queuing delays, resulting in significantly lower latency overall. And then application just get smarter in their use of caches, redundancy, gap filling, etc. All that is guaranteed to improve over time.

-- Christian Huitema

--
Network-tokens mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/network-tokens

---

From: 刘 鹏 <[email-masked]>
Date: Wed, 30 Sep 2020 01:14:03 +0000

Hi Yiannis,

I agree that offering low-latency SLA for 1% of the traffic is easier and cheaper than all internet traffic. It's better to guarantee the SLA of some critical traffic first. However, it should also strike a balance between benefits and costs.

Some new technologies such as network slice, APN may help to solve the problem and meet the demand of fine-grained traffic. Therefore, I think fine-grained traffic requirements are necessary, which can help to save network resources, and over configuration may waste network resources.

Regards,
Peng (China Mobile)

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone：13810146105
email:  [email-masked]/[email-masked]

________________________________
发件人: Apn <[email-masked]> 代表 Yiannis Yiakoumis <[email-masked]>
发送时间: 2020年9月26日 7:22
收件人: Christian Huitema <[email-masked]>
抄送: [email-masked] <[email-masked]>; 曹畅 <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; apn <[email-masked]>; Lars Eggert <[email-masked]>; pengshuping <[email-masked]>
主题: Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#5

Best,
Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO

Hi,

-- Christian Huitema

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Sep 2020 10:28:01 +0300

Hi,

On 2020-9-26, at 2:22, Yiannis Yiakoumis <[email-masked]> wrote:
> One of the first successful proof-points for SDN was Google claiming that they moved their WAN utilization to ~100%, instead of over-provisioning. It saved them lots of money. Two of the design principles that led them there were

I think these claims were made for Google's private B4 network, right? AFAIK that is a *very* different network from the public Internet. From what I recall, each transfer over B4 is scheduled over the course of a day based on various flow properties that are required to be specified, following some giant minmax-like computation.

> I can imagine offering low-latency SLA for 1% of the traffic (say video calls), is much cheaper and easier than doing this for all Internet traffic (with the cost varying whether you are in Europe/…

Sure. But that could be done with existing mechanisms, like DSCP marking. Remarking/bleaching does happen as traffic gets routed between networks, but since the stated APN use case here is within an operator network, that is under that operator's control.

> (btw: we already have SLAs today --- VoLTE is IP traffic routed through dedicated radio and wired resources and has materially better network quality and reliability than plain VoIP, and when you s…

Yup. And that happens without APN in the picture.

> If over-provisioning wins (in 10 years) it will likely be the outcome of the network community's  failure to find a good solution for traffic differentiation, rather than a verdict that these use c…

The problem isn't that we don't have good solutions for traffic differentiation. We have tons. The problem is that none of the existing ones have seen much deployment - but not because they don't work, because of other issues. I don't see APN to offer materially different/better deployment incentives than what we already have, and so IMO it would share the same fate.

Thanks,
Lars

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Wed, 30 Sep 2020 18:07:44 +0000

Hi Lars,

On Wed, Sep 30, 2020 at 12:28 AM, Lars Eggert < [email-masked] > wrote:

> 
> 
> 
> Hi,
> 
> 
> 
> 
> On 2020-9-26, at 2:22, Yiannis Yiakoumis < yiannis@ selfienetworks. com (
> [email-masked] ) > wrote:
> 
> 
> 
>> 
>> 
>> One of the first successful proof-points for SDN was Google claiming that
>> they moved their WAN utilization to ~100%, instead of over-provisioning.
>> It saved them lots of money. Two of the design principles that led them
>> there were
>> i) moving from "all packets are equally important" to "allocate resources
>> based on application-level priorities" and ii) moving from "TCP flows
>> regulated by "fair share" mechanisms" to "measure demands, and shape flows
>> at the endpoints".
>> 
>> 
> 
> 
> 
> I think these claims were made for Google's private B4 network, right?
> AFAIK that is a *very* different network from the public Internet. From
> what I recall, each transfer over B4 is scheduled over the course of a day
> based on various flow properties that are required to be specified,
> following some giant minmax-like computation.
> 
> 
> 
> 

Yes, this is for B4. While the network is different, the idea that you can build a much more cost/performance efficient WAN still stands.

> 
> 
>> 
>> 
>> I can imagine offering low-latency SLA for 1% of the traffic (say video
>> calls), is much cheaper and easier than doing this for all Internet
>> traffic (with the cost varying whether you are in Europe/US or an emerging
>> market, rural or urban, a WISP, a low-orbit satellite network, etc). Could
>> anyone from operator-land comment on the economics of
>> oversubscription/overprovision/SLAs in the mobile world?
>> 
>> 
>> 
> 
> 
> 
> Sure. But that could be done with existing mechanisms, like DSCP marking.
> Remarking/bleaching does happen as traffic gets routed between networks,
> but since the stated APN use case here is within an operator network, that
> is under that operator's control.
> 
> 
> 
> 

DSCP marking works within a single administrative domain where you have full control of endpoints and the network. The moment you want to incorporate end user devices and or third-party servers that sit out of the network, it doesn't work well. My comments are not per APN usecases per se, but rather the bigger traffic differentiation picture. (if I understand correctly, APN tries to limit things within an administrative domain to avoid having to deal with trust, security, neutrality, etc).

> 
> 
>> 
>> 
>> (btw: we already have SLAs today --- VoLTE is IP traffic routed through
>> dedicated radio and wired resources and has materially better network
>> quality and reliability than plain VoIP, and when you sign-up for a
>> broadband connection you can get 10Mbps/100Mbps/1Gbps etc).
>> 
>> 
>> 
> 
> 
> 

This happens by having vertical integration for a specific use case (phone app, phone driver, network control plane, network data plane ). I would really like to get VoLTE's reliability into my Zoom/FaceTime/WhatsApp calls, but it is not possible.

> 
> 
>> 
>> 
>> If over-provisioning wins (in 10 years) it will likely be the outcome of
>> the network community's failure to find a good solution for traffic
>> differentiation, rather than a verdict that these use cases were not
>> important enough.
>> 
>> 
>> 
> 
> 
> 
> The problem isn't that we don't have good solutions for traffic
> differentiation. We have tons. The problem is that none of the existing
> ones have seen much deployment - but not because they don't work, because
> of other issues. I don't see APN to offer materially different/better
> deployment incentives than what we already have, and so IMO it would share
> the same fate.
> 
> 
> 
> 

I would disagree here. We do have several traffic differentiation deployments that use DPI and application signatures to map traffic into SLAs at a fine granularity. It is largely inefficient cost and performance-wise, error-prone, and violates privacy and neutrality in certain occasions. But that's the one solution mostly used, for the lack of better alternatives.

Best,

Yiannis

> 
> 
> 
> Thanks,
> Lars
> 
> 
>> 
>> 
>> FWIW: there are many issues to debate around fine-grained traffic
>> differentiation beyond overprovisioning (like security, scalability,
>> privacy, net neutrality), and there are different approaches one could
>> take (APN and network tokens have different design principles and
>> priorities on these trade-offs).
>> 
>> 
>> 
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 Sep 2020 13:58:09 -0700

On 9/30/2020 11:07 AM, Yiannis Yiakoumis wrote:
> Hi Lars,
>
> On Wed, Sep 30, 2020 at 12:28 AM, Lars Eggert <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     On 2020-9-26, at 2:22, Yiannis Yiakoumis
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         One of the first successful proof-points for SDN was Google
>         claiming that they moved their WAN utilization to ~100%,
>         instead of over-provisioning. It saved them lots of money. Two
>         of the design principles that led them there were
>         i) moving from "all packets are equally important" to
>         "allocate resources based on application-level priorities" and
>         ii) moving from "TCP flows regulated by "fair share"
>         mechanisms" to "measure demands, and shape flows at the
>         endpoints".
>
>     I think these claims were made for Google's private B4 network,
>     right? AFAIK that is a *very* different network from the public
>     Internet. From what I recall, each transfer over B4 is scheduled
>     over the course of a day based on various flow properties that are
>     required to be specified, following some giant minmax-like
>     computation.
>
>
> Yes, this is for B4. While the network is different, the idea that you
> can build a much more cost/performance efficient WAN still stands.

What do you call WAN? Until now, APN was proposed for "limited domains",
which are typically access networks. WAN would imply going further, to
long distance networks used for connections between access providers. Is
that really what you have in mind?

-- Christian Huitema