Paper available: preprint of research following last year's survey
I must start by expressing heartfelt gratitude at the amenability of so many people who responded to my request for feedback to a questionnaire I posted last year <https://mailman.nanog.org/pipermail/nanog/2022-July/219870.html>. The results are out and I can share a preprint <https://www.researchgate.net/publication/376111355_A_survey_of_trends_and_motivations_regarding_Communication_Service_Providers'_metro_area_network_implementations> . It's long, but the structure of the PDF bookmarks should facilitate browsing to points of interest. Comments and criticism are welcome. Cheers, Etienne -- Ing. Etienne-Victor Depasquale
Re: Deployments of Provider Backbone Bridging (PBB)
I've had two private replies, both of which suggest that PBB has little to no share in the overall pie of the aggregation technology space, nor in the overall pie of the core technology space. However, a third correspondent states that Bard (Google's "Chat-based AI tool") claims that PBB is deployed by AT&T, Verizon, China Mobile, Deutsche Telecom and Comcast. This correspondent warns that Bard "could be hallucinating" :) Any further data points/insight would be appreciated. Cheers, Etienne On Wed, Aug 23, 2023 at 10:43 AM Etienne-Victor Depasquale wrote: > Hello folks, > > Based on data I've gathered through quantitative and qualitative > surveying, > I can detect no application of Provider Backbone Bridging (MAC-in-MAC). > Please bear with me while I clarify that I am not enquiring about Provider > Bridging (QinQ). > > I would like to ask specifically about knowledge of deployments of PBB. > If anyone would care to share data points, on- or off-list, I would love > to know about them. > I am open to anything on the subject of PBB's adoption that you are free > to share with me. > I am bound by GDPR and will anonymize any data that is not open for public > disclosure. > > Thank you! > > Etienne > > -- > Ing. Etienne-Victor Depasquale > > -- Ing. Etienne-Victor Depasquale
Deployments of Provider Backbone Bridging (PBB)
Hello folks, Based on data I've gathered through quantitative and qualitative surveying, I can detect no application of Provider Backbone Bridging (MAC-in-MAC). Please bear with me while I clarify that I am not enquiring about Provider Bridging (QinQ). I would like to ask specifically about knowledge of deployments of PBB. If anyone would care to share data points, on- or off-list, I would love to know about them. I am open to anything on the subject of PBB's adoption that you are free to share with me. I am bound by GDPR and will anonymize any data that is not open for public disclosure. Thank you! Etienne -- Ing. Etienne-Victor Depasquale
Re: AT&T in Raleigh - Durham region (NC)
> > "I need a global tier 3 engineer" with no explanation or reasoning is a > little off-putting, imo. TIm, I'm sorry that bothered you - but I was more specific in my first request. I can't be more specific because of GDPR regulations, which I am governed by. Over and out. Cheers, Etienne On Thu, Aug 17, 2023 at 8:56 PM Tim Burke wrote: > Union or not, it's always best to be descriptive when seeking help on a > mailing list, especially when involving a huge telecom conglomerate. "I > need a global tier 3 engineer" with no explanation or reasoning is a little > off-putting, imo. > -- > *From:* NANOG on behalf of TJ Trout > > *Sent:* Thursday, August 17, 2023 12:58 PM > *To:* Etienne-Victor Depasquale > *Cc:* NANOG > *Subject:* Re: AT&T in Raleigh - Durham region (NC) > > Maybe post more details. Those union folks aren't going to do anything > extra... > > On Thu, Aug 17, 2023, 12:41 AM Etienne-Victor Depasquale via NANOG < > nanog@nanog.org> wrote: > > No luck yet, and that's ok, but in case anyone is able to contact me (off > list), > I'd settle for anyone from the Global Tier 3 group of network engineers > from AT&T. > > Thank you! > > Etienne > > On Tue, Aug 15, 2023 at 12:43 PM Etienne-Victor Depasquale > wrote: > > Hello good people, > > If anyone from AT&T in the Raleigh - Durham region (NC) would care to > contact me off list, I'd be grateful. > > Cheers, > > Etienne > > -- > Ing. Etienne-Victor Depasquale > > > > -- > Ing. Etienne-Victor Depasquale > > -- Ing. Etienne-Victor Depasquale
Re: AT&T in Raleigh - Durham region (NC)
No luck yet, and that's ok, but in case anyone is able to contact me (off list), I'd settle for anyone from the Global Tier 3 group of network engineers from AT&T. Thank you! Etienne On Tue, Aug 15, 2023 at 12:43 PM Etienne-Victor Depasquale wrote: > Hello good people, > > If anyone from AT&T in the Raleigh - Durham region (NC) would care to > contact me off list, I'd be grateful. > > Cheers, > > Etienne > > -- > Ing. Etienne-Victor Depasquale > > -- Ing. Etienne-Victor Depasquale
AT&T in Raleigh - Durham region (NC)
Hello good people, If anyone from AT&T in the Raleigh - Durham region (NC) would care to contact me off list, I'd be grateful. Cheers, Etienne -- Ing. Etienne-Victor Depasquale
Re: Routed optical networks
> > Why you are so sure that they have access to traffic data for many access > networks? Well, no, I didn't say that I'm sure, actually I agree with you on everything you've said. But I can't say that it's purely speculation, as that would imply that I know more than I actually do. The overview of the method (from the 2016 - 2021 report) states the following: "The Cisco Visual Networking Index Forecast methodology has been developed based on a combination of analyst projections, in-house estimates and forecasts, and direct data collection. The analyst projections for broadband connections, video subscribers, mobile connections, and Internet application adoption come from SNL Kagan, Ovum, Informa Telecoms & Media, Infonetics, IDC, Gartner, AMI, Verto Analytics, Ookla Speedtest.net, Strategy Analytics, Screen Digest, Dell’Oro Group, Synergy, comScore, Nielsen, Maravedis, Machina Research, ACG Research, ABI Research, Media Partners Asia, IHS, International Telecommunications Union (ITU), CTIA, UN, telecommunications regulators, and others. Upon this foundation are layered Cisco’s own estimates for application adoption, minutes of use, and kilobytes per minute. The adoption, usage, and bit-rate assumptions are tied to fundamental enablers such as broadband speed and computing speed. All usage and traffic results are then validated using data shared with Cisco from service providers. Figure 1 shows the forecast methodology." Link to Figure 1 here <https://drive.google.com/file/d/1JYIXRFmlIR00qOftqXnX9Z5gKikTol7X/view?usp=sharing> . Cheers, Etienne On Thu, May 11, 2023 at 5:18 PM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > Why you are so sure that they have access to traffic data for many access > networks? > > Their BRASes market share is far from 100%. DSLAMs finished 20 years ago. > > For the cases where they support BRASes they could collect statistics. But > are they doing it? Carriers have not given permission (not even requested). > > I do not have a clue about VNI arrangement – it is magic. > > PS: Everything above and below in this thread is just my personal opinion. > > Eduard > > *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] > *Sent:* Thursday, May 11, 2023 6:03 PM > *To:* Vasilenko Eduard > *Cc:* Dave Taht ; Phil Bedard ; > NANOG > *Subject:* Re: Routed optical networks > > > > Eduard, you know the answer as well as I do, right :) ? > > > > Here's my answer: I think that Cisco can only estimate (let's not say > speculate, it has pretty bad connotations) what comes out of access > networks. > > > > No offence meant, I hope none is taken. > > > > Cheers, > > > > Etienne > > > > On Thu, May 11, 2023 at 3:47 PM Vasilenko Eduard < > vasilenko.edu...@huawei.com> wrote: > > Hi Etienne, > > Look carefully what you have shown to me. It is a only speculation again > (“predictions”). It is just a table with a collection of all predictions in > the past. Moreover, averaged between years. > > I was asking for real data from the past 5 years. Are you sure that VNI > has it? > > > > If you would find real historical data in VNI, then we would be capable to > check the table that you have shown: was the guessing right? > > I strongly suspect an answer. > > > > Eduard > > *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] > *Sent:* Thursday, May 11, 2023 2:46 PM > *To:* Vasilenko Eduard > *Cc:* Dave Taht ; Phil Bedard ; > NANOG > *Subject:* Re: Routed optical networks > > > > To clarify the table I linked to in the previous email: > > > > Cisco estimates IP traffic exchanged over the access network by both > businesses and consumers with: > > > • endpoints over managed networks and > • endpoints over unmanaged networks (“Internet traffic”). > > > Both the mobile access network and the fixed access network are > considered. > > > > Cisco considers IP traffic over managed networks to be characterized by > passage through a single service provider. > > Without explicitly referring to quality of service (QoS), > > the implication is clearly that the traffic is controlled to meet the QoS > demanded by the service level agreement (SLA). > > > > In contrast, “Internet traffic” crosses provider domains; > > typically, this traffic is delivered on the basis of providers’ best > effort. > > These two kinds of traffic complement one another and collectively are > referred to as total global IP traffic. > > > > Cheers, > > > > Etienne > > > > On Thu, May 11, 2023 at 1:37 PM Etienne-Victor Depasquale > wrote: > > Historically, this is
Re: Routed optical networks
Eduard, you know the answer as well as I do, right :) ? Here's my answer: I think that Cisco can only estimate (let's not say speculate, it has pretty bad connotations) what comes out of access networks. No offence meant, I hope none is taken. Cheers, Etienne On Thu, May 11, 2023 at 3:47 PM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > Hi Etienne, > > Look carefully what you have shown to me. It is a only speculation again > (“predictions”). It is just a table with a collection of all predictions in > the past. Moreover, averaged between years. > > I was asking for real data from the past 5 years. Are you sure that VNI > has it? > > > > If you would find real historical data in VNI, then we would be capable to > check the table that you have shown: was the guessing right? > > I strongly suspect an answer. > > > > Eduard > > *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] > *Sent:* Thursday, May 11, 2023 2:46 PM > *To:* Vasilenko Eduard > *Cc:* Dave Taht ; Phil Bedard ; > NANOG > *Subject:* Re: Routed optical networks > > > > To clarify the table I linked to in the previous email: > > > > Cisco estimates IP traffic exchanged over the access network by both > businesses and consumers with: > > > • endpoints over managed networks and > • endpoints over unmanaged networks (“Internet traffic”). > > > Both the mobile access network and the fixed access network are > considered. > > > > Cisco considers IP traffic over managed networks to be characterized by > passage through a single service provider. > > Without explicitly referring to quality of service (QoS), > > the implication is clearly that the traffic is controlled to meet the QoS > demanded by the service level agreement (SLA). > > > > In contrast, “Internet traffic” crosses provider domains; > > typically, this traffic is delivered on the basis of providers’ best > effort. > > These two kinds of traffic complement one another and collectively are > referred to as total global IP traffic. > > > > Cheers, > > > > Etienne > > > > On Thu, May 11, 2023 at 1:37 PM Etienne-Victor Depasquale > wrote: > > Historically, this is what VNI has claimed > <https://drive.google.com/file/d/1JUG70rbZfaVHC3Z2HrECMOXJ2OnmtuxV/view?usp=sharing> > . > > > > Cheers, > > > Etienne > > > > On Thu, May 11, 2023 at 1:25 PM Vasilenko Eduard < > vasilenko.edu...@huawei.com> wrote: > > I did investigate traffic for every Carrier while dealing with it as a > consultant (repeated many dozens of times). > > I have seen over a decade how traffic growth dropped year-over-year (from > 60% to 25% in 2019 when I dropped this activity in 2020 – covid blocked > travel). > > Sometimes I talk to old connections and they confirm that it is even less > now. > > In rear cases, It is typically possible to find this information on the > public Internet (I remember the case when Google disclosed traffic for > Pakistan at the conference with the explanation that 30% is attributed to > new subscribers, and an additional +30% is to more heavy content per > subscriber). > > But mostly, it was confidential information from a discussion with > Carriers – they all know very well their traffic growth. > > In general, traffic stat is pretty confidential. I did not have the > motivation to aggregate it. > > > > Sandvine is not representative of global traffic because DPI is installed > mostly for Mobiles. But Mobile subscriber is 10x less than fixed on traffic > – it is not the biggest source. Moreover, Mobiles would look better growing > because the limiting factor was on technology (5G proposed more than 4G, 4G > proposed much more than 3G) – it would probably would less disruptive in > the future. > > Fixed Carriers do not pay DPI premiums. And rarely share their traffic > publicly. Sandvine could not see it. > > > > VNI is claiming so many things. Please show where exactly they show > traffic growth (I am not interested in prediction speculations). Is it > possible to understand CAGR for the 5 last years? Is it declining or > growing? (traffic itself is for sure still growing) > > > > Of course, the disruption could come at any year and add a new S-curve > (Metaverse?). But disruption is by definition not predictable. > > > > PS: Everything above and below in this thread is just my personal opinion. > > > > Eduard > > *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] > *Sent:* Thursday, May 11, 2023 12:48 PM > *To:* Vasilenko Eduard > *Cc:* Dave Taht ; Phil Bedard ; > NANOG > *Subject:*
Re: Routed optical networks
To clarify the table I linked to in the previous email: Cisco estimates IP traffic exchanged over the access network by both businesses and consumers with: • endpoints over managed networks and • endpoints over unmanaged networks (“Internet traffic”). Both the mobile access network and the fixed access network are considered. Cisco considers IP traffic over managed networks to be characterized by passage through a single service provider. Without explicitly referring to quality of service (QoS), the implication is clearly that the traffic is controlled to meet the QoS demanded by the service level agreement (SLA). In contrast, “Internet traffic” crosses provider domains; typically, this traffic is delivered on the basis of providers’ best effort. These two kinds of traffic complement one another and collectively are referred to as total global IP traffic. Cheers, Etienne On Thu, May 11, 2023 at 1:37 PM Etienne-Victor Depasquale wrote: > Historically, this is what VNI has claimed > <https://drive.google.com/file/d/1JUG70rbZfaVHC3Z2HrECMOXJ2OnmtuxV/view?usp=sharing> > . > > Cheers, > > Etienne > > On Thu, May 11, 2023 at 1:25 PM Vasilenko Eduard < > vasilenko.edu...@huawei.com> wrote: > >> I did investigate traffic for every Carrier while dealing with it as a >> consultant (repeated many dozens of times). >> >> I have seen over a decade how traffic growth dropped year-over-year (from >> 60% to 25% in 2019 when I dropped this activity in 2020 – covid blocked >> travel). >> >> Sometimes I talk to old connections and they confirm that it is even less >> now. >> >> In rear cases, It is typically possible to find this information on the >> public Internet (I remember the case when Google disclosed traffic for >> Pakistan at the conference with the explanation that 30% is attributed to >> new subscribers, and an additional +30% is to more heavy content per >> subscriber). >> >> But mostly, it was confidential information from a discussion with >> Carriers – they all know very well their traffic growth. >> >> In general, traffic stat is pretty confidential. I did not have the >> motivation to aggregate it. >> >> >> >> Sandvine is not representative of global traffic because DPI is installed >> mostly for Mobiles. But Mobile subscriber is 10x less than fixed on traffic >> – it is not the biggest source. Moreover, Mobiles would look better growing >> because the limiting factor was on technology (5G proposed more than 4G, 4G >> proposed much more than 3G) – it would probably would less disruptive in >> the future. >> >> Fixed Carriers do not pay DPI premiums. And rarely share their traffic >> publicly. Sandvine could not see it. >> >> >> >> VNI is claiming so many things. Please show where exactly they show >> traffic growth (I am not interested in prediction speculations). Is it >> possible to understand CAGR for the 5 last years? Is it declining or >> growing? (traffic itself is for sure still growing) >> >> >> >> Of course, the disruption could come at any year and add a new S-curve >> (Metaverse?). But disruption is by definition not predictable. >> >> >> >> PS: Everything above and below in this thread is just my personal opinion. >> >> >> >> Eduard >> >> *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] >> *Sent:* Thursday, May 11, 2023 12:48 PM >> *To:* Vasilenko Eduard >> *Cc:* Dave Taht ; Phil Bedard ; >> NANOG >> *Subject:* Re: Routed optical networks >> >> >> >> Eduard, academics cite the VNI (and the Sandvine Global reports). >> >> >> >> Do you know of alternative sources that show traffic growth data you're >> more comfortable with? >> >> >> >> Cheers, >> >> >> >> Etienne >> >> >> >> On Thu, May 11, 2023 at 9:34 AM Vasilenko Eduard < >> vasilenko.edu...@huawei.com> wrote: >> >> But it is speculation, not a trend yet. >> >> I remember 10y ago every presentation started from the claim that 100B of >> IoT would drive XXX traffic. It did not happen. >> >> Now we see presentations that AI would be talking to AI that generates >> traffic. >> >> Maybe some technology would push traffic next S-curve, maybe not. It is >> still speculation. >> >> >> >> The traffic growth was stimulated (despite all VNIs) by 1) new >> subscribers, 2) video quality for subscribers. Nothing else yet. >> >> It is almost finished for both trends. We are close to t
Re: Routed optical networks
Historically, this is what VNI has claimed <https://drive.google.com/file/d/1JUG70rbZfaVHC3Z2HrECMOXJ2OnmtuxV/view?usp=sharing> . Cheers, Etienne On Thu, May 11, 2023 at 1:25 PM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > I did investigate traffic for every Carrier while dealing with it as a > consultant (repeated many dozens of times). > > I have seen over a decade how traffic growth dropped year-over-year (from > 60% to 25% in 2019 when I dropped this activity in 2020 – covid blocked > travel). > > Sometimes I talk to old connections and they confirm that it is even less > now. > > In rear cases, It is typically possible to find this information on the > public Internet (I remember the case when Google disclosed traffic for > Pakistan at the conference with the explanation that 30% is attributed to > new subscribers, and an additional +30% is to more heavy content per > subscriber). > > But mostly, it was confidential information from a discussion with > Carriers – they all know very well their traffic growth. > > In general, traffic stat is pretty confidential. I did not have the > motivation to aggregate it. > > > > Sandvine is not representative of global traffic because DPI is installed > mostly for Mobiles. But Mobile subscriber is 10x less than fixed on traffic > – it is not the biggest source. Moreover, Mobiles would look better growing > because the limiting factor was on technology (5G proposed more than 4G, 4G > proposed much more than 3G) – it would probably would less disruptive in > the future. > > Fixed Carriers do not pay DPI premiums. And rarely share their traffic > publicly. Sandvine could not see it. > > > > VNI is claiming so many things. Please show where exactly they show > traffic growth (I am not interested in prediction speculations). Is it > possible to understand CAGR for the 5 last years? Is it declining or > growing? (traffic itself is for sure still growing) > > > > Of course, the disruption could come at any year and add a new S-curve > (Metaverse?). But disruption is by definition not predictable. > > > > PS: Everything above and below in this thread is just my personal opinion. > > > > Eduard > > *From:* Etienne-Victor Depasquale [mailto:ed...@ieee.org] > *Sent:* Thursday, May 11, 2023 12:48 PM > *To:* Vasilenko Eduard > *Cc:* Dave Taht ; Phil Bedard ; > NANOG > *Subject:* Re: Routed optical networks > > > > Eduard, academics cite the VNI (and the Sandvine Global reports). > > > > Do you know of alternative sources that show traffic growth data you're > more comfortable with? > > > > Cheers, > > > > Etienne > > > > On Thu, May 11, 2023 at 9:34 AM Vasilenko Eduard < > vasilenko.edu...@huawei.com> wrote: > > But it is speculation, not a trend yet. > > I remember 10y ago every presentation started from the claim that 100B of > IoT would drive XXX traffic. It did not happen. > > Now we see presentations that AI would be talking to AI that generates > traffic. > > Maybe some technology would push traffic next S-curve, maybe not. It is > still speculation. > > > > The traffic growth was stimulated (despite all VNIs) by 1) new > subscribers, 2) video quality for subscribers. Nothing else yet. > > It is almost finished for both trends. We are close to the plateau of > these S-curves. > > For some years (2013-2020) I was carefully looking at numbers for many > countries: it was always possible to split CAGR for these 2 components. The > video part was extremely consistent between countries. The subscriber part > was 100% proportional to subscriber CAGR. > > Everything else up to now was “marketing” to say it mildly. > > > > Reminder: nothing in nature could grow indefinitely. The limit always > exists. It is only a question of when. > > > > PS: Of course, marketing people could draw you any traffic growth – it > depends just on the marketing budget. > > > > Eduard > > *From:* Dave Taht [mailto:dave.t...@gmail.com] > *Sent:* Tuesday, May 9, 2023 11:41 PM > *To:* Vasilenko Eduard > *Cc:* Phil Bedard ; Etienne-Victor Depasquale < > ed...@ieee.org>; NANOG > *Subject:* Re: Routed optical networks > > > > Up until this moment I was feeling that my take on the decline of traffic > growth was somewhat isolated, in that I have long felt that we are nearing > the top of the S curve of the data we humans can create and consume. About > the only source of future traffic growth I can think of comes from getting > more humans online, and that is a mere another doubling. > > > > On the other hand, predictions such as 640k s
Re: Routed optical networks
Eduard, academics cite the VNI (and the Sandvine Global reports). Do you know of alternative sources that show traffic growth data you're more comfortable with? Cheers, Etienne On Thu, May 11, 2023 at 9:34 AM Vasilenko Eduard < vasilenko.edu...@huawei.com> wrote: > But it is speculation, not a trend yet. > > I remember 10y ago every presentation started from the claim that 100B of > IoT would drive XXX traffic. It did not happen. > > Now we see presentations that AI would be talking to AI that generates > traffic. > > Maybe some technology would push traffic next S-curve, maybe not. It is > still speculation. > > > > The traffic growth was stimulated (despite all VNIs) by 1) new > subscribers, 2) video quality for subscribers. Nothing else yet. > > It is almost finished for both trends. We are close to the plateau of > these S-curves. > > For some years (2013-2020) I was carefully looking at numbers for many > countries: it was always possible to split CAGR for these 2 components. The > video part was extremely consistent between countries. The subscriber part > was 100% proportional to subscriber CAGR. > > Everything else up to now was “marketing” to say it mildly. > > > > Reminder: nothing in nature could grow indefinitely. The limit always > exists. It is only a question of when. > > > > PS: Of course, marketing people could draw you any traffic growth – it > depends just on the marketing budget. > > > > Eduard > > *From:* Dave Taht [mailto:dave.t...@gmail.com] > *Sent:* Tuesday, May 9, 2023 11:41 PM > *To:* Vasilenko Eduard > *Cc:* Phil Bedard ; Etienne-Victor Depasquale < > ed...@ieee.org>; NANOG > *Subject:* Re: Routed optical networks > > > > Up until this moment I was feeling that my take on the decline of traffic > growth was somewhat isolated, in that I have long felt that we are nearing > the top of the S curve of the data we humans can create and consume. About > the only source of future traffic growth I can think of comes from getting > more humans online, and that is a mere another doubling. > > > > On the other hand, predictions such as 640k should be enough for everyone > did not pan out. > > > > On the gripping hand, there has been an explosion of LLM stuff of late, > with enormous models being widely distributed in just the past month: > > > > https://lwn.net/Articles/930939/ > > > > Could the AIs takeoff lead to a resumption of traffic growth? I still > don´t think so... > > > > > > On Thu, May 4, 2023 at 10:59 PM Vasilenko Eduard via NANOG < > nanog@nanog.org> wrote: > > Disclaimer: Metaverse has not changed Metro traffic yet. Then … > > > > I am puzzled when people talk about 400GE and Tbps in the Mero context. > > For historical reasons, Metro is still about 2*2*10GE (one “2” for > redundancy, another “2” for capacity) in the majority of cases worldwide. > > How many BRASes serve more than 4/1.5=27k users in the busy hour? > > It means that 50GE is the best interface now for the majority of cases. > 2*50GE=100Gbps is good room for growth. > > Of course, exceptions could be. I know BRAS that handles 86k subscribers > (do not recommend anybody to push the limits – it was so painful). > > > > We have just 2 eyes and look at video content about 22h per week (on > average). Our eyes do not permit us to see resolution better than > particular for chosen distance (4k for typical TV, HD for smartphones, and > so on). Color depth 10bits is enough for the majority, 12bits is sure > enough for everybody. 120 frames/sec is enough for everybody. It would > never change – it is our genetics. > > Fortunately for Carriers, the traffic has a limit. You have probably seen > that every year traffic growth % is decreasing. The Internet is stabilizing > and approaching the plateau. > > How much growth is still awaiting us? 1.5? 1.4? It needs separate > research. The result would be tailored for whom would pay for the research. > > IMHO: It is not mandatory that 100GE would become massive in the metro. (I > know that 100GE is already massive in the DC CLOS) > > > > Additionally, who would pay for this traffic growth? It also limits > traffic at some point. > > I hope it would happen after we would get our 22h/4k/12bit/120hz. > > > > Now, you could argue that Metaverse would jump and multiply traffic by an > additional 2x or 3x. Then 400GE may be needed. > > Sorry, but it is speculation yet. It is not a trend like the current > (declining) traffic growth. > > > > Ed/ > > *From:* NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] > *On Behalf Of
Re: Routed optical networks
Dave, have you seen any recent output from Cisco's VNI on the matter of traffic growth? Or Sandvine's? How does it compare with your perception? Cheers, Etienne On Tue, May 9, 2023 at 10:40 PM Dave Taht wrote: > Up until this moment I was feeling that my take on the decline of traffic > growth was somewhat isolated, in that I have long felt that we are nearing > the top of the S curve of the data we humans can create and consume. About > the only source of future traffic growth I can think of comes from getting > more humans online, and that is a mere another doubling. > > On the other hand, predictions such as 640k should be enough for everyone > did not pan out. > > On the gripping hand, there has been an explosion of LLM stuff of late, > with enormous models being widely distributed in just the past month: > > https://lwn.net/Articles/930939/ > > Could the AIs takeoff lead to a resumption of traffic growth? I still > don´t think so... > > > On Thu, May 4, 2023 at 10:59 PM Vasilenko Eduard via NANOG < > nanog@nanog.org> wrote: > >> Disclaimer: Metaverse has not changed Metro traffic yet. Then … >> >> >> >> I am puzzled when people talk about 400GE and Tbps in the Mero context. >> >> For historical reasons, Metro is still about 2*2*10GE (one “2” for >> redundancy, another “2” for capacity) in the majority of cases worldwide. >> >> How many BRASes serve more than 4/1.5=27k users in the busy hour? >> >> It means that 50GE is the best interface now for the majority of cases. >> 2*50GE=100Gbps is good room for growth. >> >> Of course, exceptions could be. I know BRAS that handles 86k subscribers >> (do not recommend anybody to push the limits – it was so painful). >> >> >> >> We have just 2 eyes and look at video content about 22h per week (on >> average). Our eyes do not permit us to see resolution better than >> particular for chosen distance (4k for typical TV, HD for smartphones, and >> so on). Color depth 10bits is enough for the majority, 12bits is sure >> enough for everybody. 120 frames/sec is enough for everybody. It would >> never change – it is our genetics. >> >> Fortunately for Carriers, the traffic has a limit. You have probably seen >> that every year traffic growth % is decreasing. The Internet is stabilizing >> and approaching the plateau. >> >> How much growth is still awaiting us? 1.5? 1.4? It needs separate >> research. The result would be tailored for whom would pay for the research. >> >> IMHO: It is not mandatory that 100GE would become massive in the metro. >> (I know that 100GE is already massive in the DC CLOS) >> >> >> >> Additionally, who would pay for this traffic growth? It also limits >> traffic at some point. >> >> I hope it would happen after we would get our 22h/4k/12bit/120hz. >> >> >> >> Now, you could argue that Metaverse would jump and multiply traffic by an >> additional 2x or 3x. Then 400GE may be needed. >> >> Sorry, but it is speculation yet. It is not a trend like the current >> (declining) traffic growth. >> >> >> >> Ed/ >> >> *From:* NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] >> *On Behalf Of *Phil Bedard >> *Sent:* Thursday, May 4, 2023 8:32 PM >> *To:* Etienne-Victor Depasquale ; NANOG >> *Subject:* Re: Routed optical networks >> >> >> >> It’s not necessarily metro specific although the metro networks could >> lend themselves to overall optimizations. >> >> >> >> The adoption of ZR/ZR+ IPoWDM currently somewhat corresponds with your >> adoption of 400G since today they require a QDD port. There are 100G QDD >> ports but that’s not all that popular yet. Of course there is work to do >> something similar in QSFP28 if the power can be reduced to what is >> supported by an existing QSFP28 port in most devices. In larger networks >> with higher speed requirements and moving to 400G with QDD, using the DCO >> optics for connecting routers is kind of a no-brainer vs. a traditional >> muxponder. Whether that’s over a ROADM based optical network or not, >> especially at metro/regional distances. >> >> >> >> There are very large deployments of IPoDWDM over passive DWDM or dark >> fiber for access and aggregation networks where the aggregate required >> bandwidth doesn’t exceed the capabilities of those optics. It’s been done >> at 10G for many years. With the advent of pluggable EDFA amplifiers, you >> can even build links up to 120km*
Re: Routed optical networks
> > The optical network is made up of the photonic portion and then the > transponder/muxponder portion. > Thank you for that direct definition. I'm serious (not sarcastic). One thing I've written about in papers is the nomenclature problem, and I'm in good company. Bill Norton had written explicitly "the lexicon is important", and dwelt on that theme, in his book "the internet peering playbook". This is the source of a lot of grief. Cheers, Etienne On Mon, May 8, 2023 at 9:57 PM Phil Bedard wrote: > I guess let’s not confuse two things. The optical network is made up of > the photonic portion and then the transponder/muxponder portion. A single > term like “DWDM” can be confusing since it can refer to both. It will > take a long time (maybe never) to remove the photonic switching part of the > network. However, it’s always been cheap to deploy because optical vendors > tended to subsidize that network using sales of the other portion, the > transponders, which you buy more and more over time. Those photonic > components are expensive. > > > > On the DWDM signal portion, I’m not talking about 100ZR compared to 100G > on a transponder or DWDM line system. 100ZR has had to deal with the power > limitations of QSFP28 ports, which QDD/OSFP do not suffer from. There are > quite a few QDD pluggables in production today capable of supporting 100G > signals over 1000s of km or 400G near 1500km. Now that’s not what you can > get out of some external transponders, so those will still have their place > in high performance applications. When you move to 800G, 1.2Tbps single > channel they also have their own distance limitations. So it really > depends on the application and the network. > > > > Phil > > > > *From: *NANOG on behalf > of Mark Tinka > *Date: *Friday, May 5, 2023 at 12:55 AM > *To: *nanog@nanog.org > *Subject: *Re: Routed optical networks > > > > On 5/4/23 19:32, Phil Bedard wrote: > > > > It’s my personal opinion we aren’t to the days yet of where we can simply > build an all packet network with no photonic switching that carries all > services, but eventually (random # of years) it gets there for many > networks. There are also always going to be high performance applications > for transponders where pluggable optics aren’t a good fit. > > > I think every time the IP space gets close to running an all-packet > network, the Transport folk come out with an easier way to do it, that it's > too hard to ignore. > > Based on that, I think they will always be one step ahead, with the key > advantage being reliability of capacity over the distance, for the cost. > > The farther your fibre has to run, the costlier it gets to do it without > DWDM. > > I mean, it's only now that 100G-ZR is becoming a reality for packet > networks, and we are talking thousands of US$ for optics to get us 80km - > 120km distance. Meanwhile, DWDM vendors can get you 800Gbps per wavelength > in the same distance (or 30X that distance) far less cheaply. > > I get the appeal of not needing DWDM gear to underlay your packet > network... it's neater and offers fewer points of failure. But unless you > are dealing with very short distances and can ride a reasonable balance > between service features and switching/forwarding capacity in your > router/switch, it's going to be hard to ignore the DWDM gear if you are > trying to be a serious operation, at that scale, over a wide area. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Routed optical networks
> > I’ve seen proposals for an LSR MPLS/ROADAM type solution, where imagine > you are at a hop where in a long distance system solution, you would end up > with OEO, but instead you get directionality capability with an IP/MPLS > capable device. As mentioned previously, the 400-ZR/ZR+/ZR-Bright/+0 > optics are the latest example of that. > Jared, I understand your point in the above statement to be that directionality is cost-effectively implemented through label-switched paths, rather than (ROADM-enabled) optical path switching. Do I understand right? Thank you. Etienne On Tue, May 2, 2023 at 9:33 PM Jared Mauch wrote: > > > > On May 2, 2023, at 2:29 PM, Etienne-Victor Depasquale via NANOG < > nanog@nanog.org> wrote: > > > > On Mon, May 01, 2023 at 02:56:47PM -0600, Matt Erculiani wrote: > > > In short, the idea is that optical networks are wasteful and routers > do a > > > better job making more use of a network's capacity than ROADMs. Take > the > > > extra router hop (or 3 or 8) versus short-cutting it with an optical > > > network because the silicon is so low-latency anyway that it hardly > makes a > > > difference now. Putting more GBs per second on fewer strands means > saving a > > > lot of money on infrastructure costs. > > > > This is a very convoluted way of backing into the ole packet-switched > > vs. circuit switched decision. > > > > I don't follow. > > While ROADMs can be thought of as circuit-switchers, > > the number of concurrent clients and switching latency put ROADMs on a > different operational level than packet switchers, right? > > > I’ve seen proposals for an LSR MPLS/ROADAM type solution, where imagine > you are at a hop where in a long distance system solution, you would end up > with OEO, but instead you get directionality capability with an IP/MPLS > capable device. As mentioned previously, the 400-ZR/ZR+/ZR-Bright/+0 > optics are the latest example of that. > > I know of a few companies that have looked at solutions like this, and can > expect there to be some interesting solutions that would appear as a > result. Optical line systems tend to have pretty low power requirements > compared to a router, but some of the routers are getting pretty low power > as well when it comes to the power OPEX/bit, and if you have the ability to > deliver services as an integrated packet optical you could see reduced > costs and simplified components/sparing. > > I’ll also say that I’ve not yet seen the price compression that I had > expected in the space yet, but I figure that’s coming. We are seeing the > bits/watt ratio improve though, so for the same or less power consumption > you get more bits. Some of this technology stuff is truly magical. > > - Jared -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Routed optical networks
Very helpful observations, Matt, thank you. How comfortably does the phrase "routed optical networks over Ethernet without ROADMs" sit with you? I mean: would you accept a limitation of "optical network" to the case of a network without optical layer switching (of the type done by add-drop multiplexers)? Cheers, Etienne On Mon, May 1, 2023 at 10:57 PM Matt Erculiani wrote: > Hi Etienne > > In short, the idea is that optical networks are wasteful and routers do a > better job making more use of a network's capacity than ROADMs. Take the > extra router hop (or 3 or 8) versus short-cutting it with an optical > network because the silicon is so low-latency anyway that it hardly makes a > difference now. Putting more GBs per second on fewer strands means saving a > lot of money on infrastructure costs. > > 400G ZR comes to mind as a foundational technology since it basically made > active optical muxponder equipment obsolete in the metro. The savings here > means telcos/enterprises can afford more router ports, which we've already > established can utilize paths more efficiently anyway. Otherwise, this is > more of a concept and can be executed with a variety of pre-existing > technologies, or someone's new secret sauce that bakes everything together > like SD-WAN did to its constituent technologies. > > -Matt > > > On Mon, May 1, 2023 at 12:30 PM Etienne-Victor Depasquale via NANOG < > nanog@nanog.org> wrote: > >> Hello folks, >> >> Simple question: does "routed optical networks" have a clear meaning in >> the metro area context, or not? >> >> Put differently: does it call to mind a well-defined stack of >> technologies in the control and data planes of metro-area networks? >> >> I'm asking because I'm having some thoughts about the clarity of this >> term, in the process of carrying out a qualitative survey of the results of >> the metro-area networks survey. >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Matt Erculiani > ERCUL-ARIN > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Routed optical networks
Hello Eve, Thank you for weighing in; I'm eager for feedback from the field. This eagerness stems from my work, over the past two years, to form my understanding of where current- and next-gen metro area networks are heading. I need this understanding to help academics in my field of specialization to better understand energy consumption in metro-area networks. Your observation about elimination of OTN resonates well with what I've heard from webinars, and what I've read in studies. It also matches what I've shown in the graphic I linked to in an earlier post in this thread (this graphic <https://drive.google.com/open?id=1HkXAbd2PIQF_ACOeQYDtpeGxTEaTT1Y7&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> ). However, the larger operators are less inclined to drop OTN as a server layer network (layer network used as defined in G.805). Indeed, part of the scope of the question leading to the results shown, actually was to try to understand the prevalence of OTN in operators' current networks. As regards greenfield, the *NOG results are a bit more nuanced <https://drive.google.com/file/d/1Hl-UKJNMTguGCH3_g9cTiSDBdQAK4lya/view?usp=sharing> . IP/MPLS over Ethernet over DWDM with ROADMs for node bypass gets 34% of the vote, up from about 13% of what is currently in their networks. Cheers, Etienne On Tue, May 2, 2023 at 4:01 PM Eve Griliches wrote: > Hi Etienne, > Below is our (Cisco) definition of the Routed Optical Network. The goal, > metro or long haul or subsea, is to reduce the number of control planes. By > migration TDM traffic using CEM or PLE to the IP layer, you eliminate the > OTN control plane and management. Eventually, when standards are settled > the ultimate goal is to have a single control plane for the network. I'm > not trying to be a commercial here, but you can read more in the resources > section on this page: > https://www.cisco.com/c/en/us/solutions/service-provider/routed-optical-networking/index.html > HTH, > Eve > > Routed optical networking, is an architecture that delivers improved > operational efficiencies and simplicity. The solution works by merging IP > and private line services onto a single layer where all the switching is > done at Layer 3. Routers are connected with standardized 400G ZR/ZR+ > coherent pluggable optics. > > With a single service layer based upon IP, flexible management tools can > leverage telemetry and model-driven programmability to streamline lifecycle > operations. This simplified architecture integrates open data models and > standard APIs, enabling a provider to focus on automation initiatives for a > simpler topology. > > On Mon, May 1, 2023 at 2:30 PM Etienne-Victor Depasquale via NANOG < > nanog@nanog.org> wrote: > >> Hello folks, >> >> Simple question: does "routed optical networks" have a clear meaning in >> the metro area context, or not? >> >> Put differently: does it call to mind a well-defined stack of >> technologies in the control and data planes of metro-area networks? >> >> I'm asking because I'm having some thoughts about the clarity of this >> term, in the process of carrying out a qualitative survey of the results of >> the metro-area networks survey. >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Routed optical networks
Josh, thank you, your remarks (and those of Matt and Eduard) are helping me to understand better. For some context, please look at this graphic <https://drive.google.com/open?id=1HkXAbd2PIQF_ACOeQYDtpeGxTEaTT1Y7&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> that shows the results of the question "Which of the following best describes your current dominant form of metro-aggregation?" The left bar chart shows *NOG reponses; the right bar chart shows responses obtained through market research among Tier 1 and regional operators. Operator group respondents overwhelmingly selected "routed optical networks over Ethernet without ROADMs". Now, during an interview I held to assess the answers, the interviewee (an experienced network engineer) questioned the meaning. I realized that I may have been conditioned by Cisco marketing (I attend a few webinars), and I wanted to understand what respondents understood. Summarizing an answer to your observation, I was conditioned by Cisco marketing. Cheers, Etienne On Mon, May 1, 2023 at 10:30 PM Josh Luthman wrote: > Maybe some clarification as to what you're asking for would help. You're > mixing fiber, networks, and a MAN. Fiber is just the medium. It could be > for IP switching or projecting a light show. Are you asking if there are > diverse paths throughout a metro area? > > On Mon, May 1, 2023 at 2:30 PM Etienne-Victor Depasquale via NANOG < > nanog@nanog.org> wrote: > >> Hello folks, >> >> Simple question: does "routed optical networks" have a clear meaning in >> the metro area context, or not? >> >> Put differently: does it call to mind a well-defined stack of >> technologies in the control and data planes of metro-area networks? >> >> I'm asking because I'm having some thoughts about the clarity of this >> term, in the process of carrying out a qualitative survey of the results of >> the metro-area networks survey. >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Routed optical networks
Hello folks, Simple question: does "routed optical networks" have a clear meaning in the metro area context, or not? Put differently: does it call to mind a well-defined stack of technologies in the control and data planes of metro-area networks? I'm asking because I'm having some thoughts about the clarity of this term, in the process of carrying out a qualitative survey of the results of the metro-area networks survey. Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Request for additional data points
Good people, Last year, I collected some data for my study from this list. I published a summary of the data for a short time and recently sent a snapshot regarding metro area access technologies. I am currently writing my paper and would love to have some additional data points. If anyone who has ***not yet contributed*** would like to do so, I am still collecting data here: https://forms.gle/ypcCZvrHbKXRbXqn9 Sincerely, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for comments
Quick (and critical) correction: bar charts on the ***left*** are from *NOGs; bar charts on the ***right*** are from commissioned market research. Cheers, Etienne On Tue, Mar 7, 2023 at 2:06 PM Etienne-Victor Depasquale wrote: > The picture changes significantly when an operator's choice is weighted by > his current subscriber base. > Evidently, incumbents have lots of copper media, while smaller operators > (more agile?) are laying fibre and mostly growing GPON on it. > > Rebuttals are welcome ! > > Unweighted data > <https://drive.google.com/open?id=1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> > > Weighted data > <https://drive.google.com/file/d/1fMLiEGbvaD4pqCmQM75HWYoR37XaiHFQ/view?usp=sharing> > (weighted by number of subscribers) > > Cheers, > > Etienne > > > On Fri, Mar 3, 2023 at 5:32 PM Etienne-Victor Depasquale > wrote: > >> I've updated the graphic >> <https://drive.google.com/open?id=1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> >> with one other data point and increased the graphic's size (following >> feedback). >> >> In particular, I'd like to understand why there are so many operators who >> consider Active Ethernet (p2p) >> to be their largest and/or fastest growing access technology. >> >> Would anyone care to give an opinion / interpretation / perspective / >> other ? >> >> Cheers, >> >> Etienne >> >> On Wed, Mar 1, 2023 at 9:24 AM Etienne-Victor Depasquale >> wrote: >> >>> Good people of NANOG, >>> >>> Please find here >>> <https://drive.google.com/file/d/1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR/view?usp=sharing> >>> a snapshot of two datasets concerning access technologies in the metro area. >>> >>> The bar chart on the right summarizes data I collected last year from >>> *NOGs; >>> the bar chart on the left summarizes data received last year from Tier 1 >>> and/or regional operators (incumbents). >>> The y-axis shows cumulative responses for an option; the x-axis shows >>> (hopefully unambiguous) monikers for the access technologies. >>> >>> Would anyone care to comment on how well this matches his/her perception >>> of the current state of deployments? >>> >>> Cheers, >>> >>> Etienne >>> >>> -- >>> Ing. Etienne-Victor Depasquale >>> Assistant Lecturer >>> Department of Communications & Computer Engineering >>> Faculty of Information & Communication Technology >>> University of Malta >>> Web. https://www.um.edu.mt/profile/etiennedepasquale >>> >> >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for comments
The picture changes significantly when an operator's choice is weighted by his current subscriber base. Evidently, incumbents have lots of copper media, while smaller operators (more agile?) are laying fibre and mostly growing GPON on it. Rebuttals are welcome ! Unweighted data <https://drive.google.com/open?id=1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> Weighted data <https://drive.google.com/file/d/1fMLiEGbvaD4pqCmQM75HWYoR37XaiHFQ/view?usp=sharing> (weighted by number of subscribers) Cheers, Etienne On Fri, Mar 3, 2023 at 5:32 PM Etienne-Victor Depasquale wrote: > I've updated the graphic > <https://drive.google.com/open?id=1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> > with one other data point and increased the graphic's size (following > feedback). > > In particular, I'd like to understand why there are so many operators who > consider Active Ethernet (p2p) > to be their largest and/or fastest growing access technology. > > Would anyone care to give an opinion / interpretation / perspective / > other ? > > Cheers, > > Etienne > > On Wed, Mar 1, 2023 at 9:24 AM Etienne-Victor Depasquale > wrote: > >> Good people of NANOG, >> >> Please find here >> <https://drive.google.com/file/d/1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR/view?usp=sharing> >> a snapshot of two datasets concerning access technologies in the metro area. >> >> The bar chart on the right summarizes data I collected last year from >> *NOGs; >> the bar chart on the left summarizes data received last year from Tier 1 >> and/or regional operators (incumbents). >> The y-axis shows cumulative responses for an option; the x-axis shows >> (hopefully unambiguous) monikers for the access technologies. >> >> Would anyone care to comment on how well this matches his/her perception >> of the current state of deployments? >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for comments
I've updated the graphic <https://drive.google.com/open?id=1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR&authuser=etienne.depasquale%40um.edu.mt&usp=drive_fs> with one other data point and increased the graphic's size (following feedback). In particular, I'd like to understand why there are so many operators who consider Active Ethernet (p2p) to be their largest and/or fastest growing access technology. Would anyone care to give an opinion / interpretation / perspective / other ? Cheers, Etienne On Wed, Mar 1, 2023 at 9:24 AM Etienne-Victor Depasquale wrote: > Good people of NANOG, > > Please find here > <https://drive.google.com/file/d/1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR/view?usp=sharing> > a snapshot of two datasets concerning access technologies in the metro area. > > The bar chart on the right summarizes data I collected last year from > *NOGs; > the bar chart on the left summarizes data received last year from Tier 1 > and/or regional operators (incumbents). > The y-axis shows cumulative responses for an option; the x-axis shows > (hopefully unambiguous) monikers for the access technologies. > > Would anyone care to comment on how well this matches his/her perception > of the current state of deployments? > > Cheers, > > Etienne > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Request for comments
Good people of NANOG, Please find here <https://drive.google.com/file/d/1eZZeqbDaTj6nSJJDdK0iu5Xm9Z_691rR/view?usp=sharing> a snapshot of two datasets concerning access technologies in the metro area. The bar chart on the right summarizes data I collected last year from *NOGs; the bar chart on the left summarizes data received last year from Tier 1 and/or regional operators (incumbents). The y-axis shows cumulative responses for an option; the x-axis shows (hopefully unambiguous) monikers for the access technologies. Would anyone care to comment on how well this matches his/her perception of the current state of deployments? Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Random Early Detect and streaming video
> > What does 'egress priority queueing' mean? Do you mean 'send all X, > before any Y, send all Y before any Z'? If this, then this must have > been quite some time now, as since traffic managers were implemented > in hardware ages ago, this hasn't been available. > As you'll probably remember, I'm just an academic who tries to keep up with the times. What I can add is that in the latest MEF CECP (Carrier Ethernet Certified Professional) courseware (Blueprint D), egress bandwidth profiles that are based on token buckets are still actively advocated as a means of applying QoS. Cheers, Etienne On Tue, Nov 8, 2022 at 10:00 AM Saku Ytti wrote: > Hey, > > > On Mon, 7 Nov 2022 at 21:58, Graham Johnston > wrote: > > > > I've been involved in service provider networks, small retail ISPs, for > 20+ years now. Largely though, we've never needed complex QoS, as at > $OLD_DAY_JOB, we had been consistently positioned to avoid regular link > congestion by having sufficient capacity. In the few instances when we've > had link congestion, egress priority queuing met our needs. > > What does 'egress priority queueing' mean? Do you mean 'send all X, > before any Y, send all Y before any Z'? If this, then this must have > been quite some time now, as since traffic managers were implemented > in hardware ages ago, this hasn't been available. And the only thing > that has been available has been 'X has guaranteed rate X1, Y has Y1 > and Z has Z1' and love it or hate it, that's the QoS tool industry has > decided you need. > > > combine that with the buffering and we should adjust the drop profile to > kick in at a higher percentage. Today we use 70% to start triggering the > drop behavior, but my head tells me it should be higher. The reason I am > saying this is that we are dropping packets ahead of full link congestion, > yes that is what RED was designed to do, but I surmise that we are making > this application worse than is actually intended. > > I wager almost no one knows what their RED curve is, and different > vendors have different default curves which is then the curve almost > everyone uses. Some use a RED curve such that everything is basically > tail drop (Juniper, 0% drop at 96% fill and 100% drop at 98% fill). > Some are linear. Some allow defining just two points, some allow > defining 64 points. And almost no one has any idea what their curve > is, i.e. mostly it doesn't matter. If it usually mattered, we'd all > know what the curve is and why. As practical example Juniper has > basically > > In your case, I assume you have at least two points with 0% drop at > 69% fill, then a linear curve from 70% to 100% fill with 1% to 100% > drop. It doesn't seem outright wrong to me. You have 2-3 goals here, > to avoid synchronising TCP flows so that you have steady fill, instead > of wave-like behaviour and to reduce queueing delay for packets not > dropped, which would experience as long a delay as there is queue if > tail dropped. You could have a 3rd possible goal, if you map more than > 1 class of packets into the same queue you can still give them > different curves, so during congestion in a single queue can show two > different behaviours depending on packet. > So what is the problem you're trying to fix? Can you measure it? > > I suspect in a modern high speed network with massive amounts of flows > the wave-like synchronisation is not a problem. If you can't measure > it or If your only goal is to reduce queueing delay because you have > 'strategic' congestion, perhaps instead of worrying about RED, use > tail only and reduce queue size to something that is tolerable 1ms-5ms > max? > > -- > ++ytti > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for help: academic study (questionnaire)
Here's an update on the analytics <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> . I'm concurrently running a parallel survey with support from a market research team. The results will be part of a submission to a journal, with the scope of energy-aware telecommunications. (I admit that the work is taking longer than I expected back in June) Any feedback/discussion which you, the prime exponents of our industry's cutting operational edge (I am just an academic), would care to share with me, would be a most valuable asset. With sincere thanks and regards to all, Etienne On Mon, Sep 12, 2022 at 12:24 PM Etienne-Victor Depasquale wrote: > I'm truly grateful for the response received > <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> > (available until Wednesday 8pm CET) > > I'm short on North American - headquartered telcos / MSOs; any support > would be deeply appreciated (link to questionnaire is here > <https://forms.gle/U9Ucd9KcBA7Axkaj7>). > > With thanks, > > Etienne > > On Mon, Jul 25, 2022 at 10:09 AM Etienne-Victor Depasquale > wrote: > >> ***Apologies for cross-posting*** >> >> Interim results >> <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> >> (available >> until 26th July, 10 am CET) >> >> Link to fill in survey <https://forms.gle/NTiRdQVfuQKCJKr78> (for those >> who have been unable to do so and might be interested in doing so). >> >> Sincere and heartfelt thanks to those who have already filled in the >> survey. >> >> Etienne >> >> On Thu, Jul 21, 2022 at 12:56 PM Etienne-Victor Depasquale < >> ed...@ieee.org> wrote: >> >>> Dear NANOGers, >>> >>> Payback time (unprocessed, interim aggregate analytics, more to come >>> later): >>> Next-generation metro area networks (google.com) >>> <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> >>> , >>> available until tomorrow Friday 22nd 8pm CET. >>> >>> I need more data (42/50 received/desired - at time of publication), >>> especially from MSOs >>> (but please, if you can, whatever your operator genre, do >>> answer/distribute/nudge). >>> >>> Cheers, >>> >>> Etienne >>> >>> On Thu, Jul 14, 2022 at 12:34 PM Etienne-Victor Depasquale < >>> ed...@ieee.org> wrote: >>> >>>> I'm at 15/50 (received/desired) responses - thank you so much to those >>>> who've helped. >>>> >>>> Please, if you can answer/distribute/nudge, it would help to make this >>>> study meaningful >>>> (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA) >>>> >>>> Thank you for your patience with this reminder of mine. >>>> >>>> >>>> Cheers, >>>> >>>> Etienne >>>> >>>> On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale < >>>> ed...@ieee.org> wrote: >>>> >>>>> Hello NANOGers, >>>>> >>>>> >>>>> I'm asking for your help through your response to a questionnaire >>>>> that forms part of an academic study that I'm carrying out >>>>> <https://forms.gle/AAJokyg98JLW7Ti6A>. >>>>> >>>>> The study is directed solely towards facilitating understanding of >>>>> metro area networks, for analysts who approach from the perspective of >>>>> energy consumption. >>>>> >>>>> The study is anonymous (no individual or company names are solicited), >>>>> and individual responses will only be used in aggregate. >>>>> >>>>> I shall send a digest of the survey to the mailing list, and will >>>>> correspond with respondents who would like a copy of the paper which I >>>>> intend to produce with the results. >>>>> >>>>> >>>>> Yours sincerely, >>>>> >>>>> Etienne >>>>> >>>>> -- >>>>> Ing. Etienne-Victor Depasquale >>>>> Assistant Lecturer >>>>> Department of Communications & Computer Engineering >>>>> Faculty of Information & Communication Technology >>>>> University of Malta >>>>> Web. https://www.um.edu.mt/profile/etiennedepasquale >
Re: Request for help: academic study (questionnaire)
I'm truly grateful for the response received <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> (available until Wednesday 8pm CET) I'm short on North American - headquartered telcos / MSOs; any support would be deeply appreciated (link to questionnaire is here <https://forms.gle/U9Ucd9KcBA7Axkaj7>). With thanks, Etienne On Mon, Jul 25, 2022 at 10:09 AM Etienne-Victor Depasquale wrote: > ***Apologies for cross-posting*** > > Interim results > <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> > (available > until 26th July, 10 am CET) > > Link to fill in survey <https://forms.gle/NTiRdQVfuQKCJKr78> (for those > who have been unable to do so and might be interested in doing so). > > Sincere and heartfelt thanks to those who have already filled in the > survey. > > Etienne > > On Thu, Jul 21, 2022 at 12:56 PM Etienne-Victor Depasquale > wrote: > >> Dear NANOGers, >> >> Payback time (unprocessed, interim aggregate analytics, more to come >> later): >> Next-generation metro area networks (google.com) >> <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> >> , >> available until tomorrow Friday 22nd 8pm CET. >> >> I need more data (42/50 received/desired - at time of publication), >> especially from MSOs >> (but please, if you can, whatever your operator genre, do >> answer/distribute/nudge). >> >> Cheers, >> >> Etienne >> >> On Thu, Jul 14, 2022 at 12:34 PM Etienne-Victor Depasquale < >> ed...@ieee.org> wrote: >> >>> I'm at 15/50 (received/desired) responses - thank you so much to those >>> who've helped. >>> >>> Please, if you can answer/distribute/nudge, it would help to make this >>> study meaningful >>> (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA) >>> >>> Thank you for your patience with this reminder of mine. >>> >>> >>> Cheers, >>> >>> Etienne >>> >>> On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale >>> wrote: >>> >>>> Hello NANOGers, >>>> >>>> >>>> I'm asking for your help through your response to a questionnaire that >>>> forms part of an academic study that I'm carrying out >>>> <https://forms.gle/AAJokyg98JLW7Ti6A>. >>>> >>>> The study is directed solely towards facilitating understanding of >>>> metro area networks, for analysts who approach from the perspective of >>>> energy consumption. >>>> >>>> The study is anonymous (no individual or company names are solicited), >>>> and individual responses will only be used in aggregate. >>>> >>>> I shall send a digest of the survey to the mailing list, and will >>>> correspond with respondents who would like a copy of the paper which I >>>> intend to produce with the results. >>>> >>>> >>>> Yours sincerely, >>>> >>>> Etienne >>>> >>>> -- >>>> Ing. Etienne-Victor Depasquale >>>> Assistant Lecturer >>>> Department of Communications & Computer Engineering >>>> Faculty of Information & Communication Technology >>>> University of Malta >>>> Web. https://www.um.edu.mt/profile/etiennedepasquale >>>> >>> >>> >>> -- >>> Ing. Etienne-Victor Depasquale >>> Assistant Lecturer >>> Department of Communications & Computer Engineering >>> Faculty of Information & Communication Technology >>> University of Malta >>> Web. https://www.um.edu.mt/profile/etiennedepasquale >>> >> >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: IoT - The end of the internet
> > because our lizard brains have a hard time comprehending exponential > growth > Don't forget how we pontificate on how well we understand infinity. Cheers, Etienne On Wed, Aug 10, 2022 at 6:09 PM Chris Wright < chris.wri...@commnetbroadband.com> wrote: > That’s just humans in general, and it certainly isn’t limited to our > outlook on the future of the internet. Big advancements will always take us > by surprise because our lizard brains have a hard time comprehending > exponential growth. Someone please stop me here before I get on my > Battery-EV soapbox. :D > > > > Chris > > > > *From:* NANOG *On > Behalf Of *Tom Beecher > *Sent:* Wednesday, August 10, 2022 9:25 AM > *To:* Christopher Wolff > *Cc:* NANOG > *Subject:* Re: IoT - The end of the internet > > > > It always amazes me how an industry that has , since its inception, been > constantly solving new problems to make things work, always finds a way to > assume the next problem will be unsolvable. > > > > On Tue, Aug 9, 2022 at 10:23 PM Christopher Wolff > wrote: > > Hi folks, > > Has anyone proposed that the adoption of billions of IoT devices will > ultimately ‘break’ the Internet? > > It’s not a rhetorical question I promise, just looking for a journal or > other scholarly article that implies that the Internet is doomed. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: 400G forwarding - how does it work?
can't do anything, until the PPE before in line is >> done. >> >> >> >> Today Cisco and Juniper do 'proper' CoPP, that is, they do ingressACL >> before and after lookup, before is normally needed for ingressACL but after >> lookup ingressACL is needed for CoPP (we only know after lookup if it is >> control-plane packet). Nokia doesn't do this at all, and I bet they can't >> do it, because if they'd add it in the core where it needs to be in line, >> total PPS would go down. as there is no budget for additional ACL. Instead >> all control-plane packets from ingressFP are sent to control plane FP, and >> inshallah we don't congest the connection there or it. >> >> >> >> >> >> > >> >> > Cheers, >> >> > James. >> >> >> >> >> >> >> >> -- >> >> ++ytti >> > > > -- > ++ytti > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for help: academic study (questionnaire)
***Apologies for cross-posting*** Interim results <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> (available until 26th July, 10 am CET) Link to fill in survey <https://forms.gle/NTiRdQVfuQKCJKr78> (for those who have been unable to do so and might be interested in doing so). Sincere and heartfelt thanks to those who have already filled in the survey. Etienne On Thu, Jul 21, 2022 at 12:56 PM Etienne-Victor Depasquale wrote: > Dear NANOGers, > > Payback time (unprocessed, interim aggregate analytics, more to come > later): > Next-generation metro area networks (google.com) > <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> > , > available until tomorrow Friday 22nd 8pm CET. > > I need more data (42/50 received/desired - at time of publication), > especially from MSOs > (but please, if you can, whatever your operator genre, do > answer/distribute/nudge). > > Cheers, > > Etienne > > On Thu, Jul 14, 2022 at 12:34 PM Etienne-Victor Depasquale > wrote: > >> I'm at 15/50 (received/desired) responses - thank you so much to those >> who've helped. >> >> Please, if you can answer/distribute/nudge, it would help to make this >> study meaningful >> (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA) >> >> Thank you for your patience with this reminder of mine. >> >> >> Cheers, >> >> Etienne >> >> On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale >> wrote: >> >>> Hello NANOGers, >>> >>> >>> I'm asking for your help through your response to a questionnaire that >>> forms part of an academic study that I'm carrying out >>> <https://forms.gle/AAJokyg98JLW7Ti6A>. >>> >>> The study is directed solely towards facilitating understanding of metro >>> area networks, for analysts who approach from the perspective of energy >>> consumption. >>> >>> The study is anonymous (no individual or company names are solicited), >>> and individual responses will only be used in aggregate. >>> >>> I shall send a digest of the survey to the mailing list, and will >>> correspond with respondents who would like a copy of the paper which I >>> intend to produce with the results. >>> >>> >>> Yours sincerely, >>> >>> Etienne >>> >>> -- >>> Ing. Etienne-Victor Depasquale >>> Assistant Lecturer >>> Department of Communications & Computer Engineering >>> Faculty of Information & Communication Technology >>> University of Malta >>> Web. https://www.um.edu.mt/profile/etiennedepasquale >>> >> >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for help: academic study (questionnaire)
Dear NANOGers, Payback time (unprocessed, interim aggregate analytics, more to come later): Next-generation metro area networks (google.com) <https://docs.google.com/forms/d/1kJnEjukNDGC4JARuhgBI0HUUrQ8UNA-G71Aa6heaK8U/viewanalytics> , available until tomorrow Friday 22nd 8pm CET. I need more data (42/50 received/desired - at time of publication), especially from MSOs (but please, if you can, whatever your operator genre, do answer/distribute/nudge). Cheers, Etienne On Thu, Jul 14, 2022 at 12:34 PM Etienne-Victor Depasquale wrote: > I'm at 15/50 (received/desired) responses - thank you so much to those > who've helped. > > Please, if you can answer/distribute/nudge, it would help to make this > study meaningful > (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA) > > Thank you for your patience with this reminder of mine. > > > Cheers, > > Etienne > > On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale > wrote: > >> Hello NANOGers, >> >> >> I'm asking for your help through your response to a questionnaire that >> forms part of an academic study that I'm carrying out >> <https://forms.gle/AAJokyg98JLW7Ti6A>. >> >> The study is directed solely towards facilitating understanding of metro >> area networks, for analysts who approach from the perspective of energy >> consumption. >> >> The study is anonymous (no individual or company names are solicited), >> and individual responses will only be used in aggregate. >> >> I shall send a digest of the survey to the mailing list, and will >> correspond with respondents who would like a copy of the paper which I >> intend to produce with the results. >> >> >> Yours sincerely, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Request for help: academic study (questionnaire)
I'm at 15/50 (received/desired) responses - thank you so much to those who've helped. Please, if you can answer/distribute/nudge, it would help to make this study meaningful (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA) Thank you for your patience with this reminder of mine. Cheers, Etienne On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale wrote: > Hello NANOGers, > > > I'm asking for your help through your response to a questionnaire that > forms part of an academic study that I'm carrying out > <https://forms.gle/AAJokyg98JLW7Ti6A>. > > The study is directed solely towards facilitating understanding of metro > area networks, for analysts who approach from the perspective of energy > consumption. > > The study is anonymous (no individual or company names are solicited), and > individual responses will only be used in aggregate. > > I shall send a digest of the survey to the mailing list, and will > correspond with respondents who would like a copy of the paper which I > intend to produce with the results. > > > Yours sincerely, > > Etienne > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Request for help: academic study (questionnaire)
Hello NANOGers, I'm asking for your help through your response to a questionnaire that forms part of an academic study that I'm carrying out <https://forms.gle/AAJokyg98JLW7Ti6A>. The study is directed solely towards facilitating understanding of metro area networks, for analysts who approach from the perspective of energy consumption. The study is anonymous (no individual or company names are solicited), and individual responses will only be used in aggregate. I shall send a digest of the survey to the mailing list, and will correspond with respondents who would like a copy of the paper which I intend to produce with the results. Yours sincerely, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
> > Considered that, but that would be obvious - we need optics :-). > Agreed - but wouldn't it be fair to say that, nonetheless, the availability of an MSA supports the development of network architecture? With an MSA, there is some limited, common basis for a discussion in an ecosystem of vendors and network operators. That should support development of architecture. Cheers, Etienne On Wed, May 18, 2022 at 10:32 AM Mark Tinka wrote: > > > On 5/18/22 08:28, Etienne-Victor Depasquale via NANOG wrote: > > > Just to add a bit of fun to the mix - perhaps multi-source agreement > > was intended :) > > Considered that, but that would be obvious - we need optics :-). > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
> > In your fair proposal, MSA is related to network architecture as a way > to standardise pluggable (optics). But as always standards are > incomplete, ambiguous and do not guarantee interoperability, so it > will take some time for industry to decide what is 'correct' > interpretation of MSA. Implying when you buy early in life cycle new > optics, you may want to source more carefully and test, compared to > buying later in life cycle sourcing pluggables anywhere with 0 testing > is relatively low risk. > Amen to that. Cheers, Etienne On Wed, May 18, 2022 at 8:39 AM Saku Ytti wrote: > We could also add an explanation to our proposals for the acronym. :) > > In your fair proposal, MSA is related to network architecture as a way > to standardise pluggable (optics). But as always standards are > incomplete, ambiguous and do not guarantee interoperability, so it > will take some time for industry to decide what is 'correct' > interpretation of MSA. Implying when you buy early in life cycle new > optics, you may want to source more carefully and test, compared to > buying later in life cycle sourcing pluggables anywhere with 0 testing > is relatively low risk. > > > On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG > wrote: > > > > Just to add a bit of fun to the mix - perhaps multi-source agreement was > intended :) > > > > Cheers, > > > > Etienne > > > > On Wed, May 18, 2022 at 3:59 AM Martin Hannigan > wrote: > >> > >> > >> > >> All, > >> > >> Why do MSA’s matter as related to network architecture? > >> > >> Thanks all — > >> > >> -M< > >> > >> > >> > > > > > > -- > > Ing. Etienne-Victor Depasquale > > Assistant Lecturer > > Department of Communications & Computer Engineering > > Faculty of Information & Communication Technology > > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > > > > -- > ++ytti > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: MSA’s and network architecture
Just to add a bit of fun to the mix - perhaps multi-source agreement was intended :) Cheers, Etienne On Wed, May 18, 2022 at 3:59 AM Martin Hannigan wrote: > > > All, > > Why do MSA’s matter as related to network architecture? > > Thanks all — > > -M< > > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
A quick note of appreciation
I've occasionally posted to this list, but mostly take a seat in the audience. *** And what a show this is! *** First-class technical discussions, updated news, timely responses. God bless NANOG, and may this community keep up its invaluable contribution to networking, and thereby, to all of society. With humble gratitude, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: 100GbE beyond 40km
Bear with my ignorance, I'm genuinely surprised at this: Does this have to be Ethernet? You could look into line gear with coherent > optics. > Specifically, do you mean something like: "does this have to be IEEE-standardized all the way down to L1 optics?" Because you can transmit Ethernet frames over line gear with coherent optics, right ? Please don't flame me, I'm just ignorant and willing to learn. Cheers, Etienne On Fri, Sep 24, 2021 at 11:25 PM Bill Blackford wrote: > Does this have to be Ethernet? You could look into line gear with coherent > optics. IIRC, they have built-in chromatic dispersion compensation, and > depending on the card, would include amplification. > > On Fri, Sep 24, 2021 at 1:40 PM Randy Carpenter > wrote: > >> >> How is everyone accomplishing 100GbE at farther than 40km distances? >> >> Juniper is saying it can't be done with anything they offer, except for a >> single CFP-based line card that is EOL. >> >> There are QSFP "ZR" modules from third parties, but I am hesitant to try >> those without there being an equivalent official part. >> >> >> The application is an ISP upgrading from Nx10G, where one of their fiber >> paths is ~35km and the other is ~60km. >> >> >> >> thanks, >> -Randy >> > > > -- > Bill Blackford > > Logged into reality and abusing my sudo privileges. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: IPv6 woes - RFC
> > Without the membership fees, of course :-). Membership fees can be painful, that's for sure. They do have positive aspects, though :) Cheers, Etienne On Wed, Sep 8, 2021 at 9:38 AM Mark Tinka wrote: > > > On 9/8/21 09:35, Etienne-Victor Depasquale wrote: > > > If the Telecom Infra Project > <https://telecominfraproject.com/participants/> is a good indicator > of what operators can achieve by uniting, > then you're on a good trajectory. > > > Without the membership fees, of course :-). > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: IPv6 woes - RFC
> > I'm not sure if there needs to be a separate "cabal" amongst the major > network operators that cover every corner of the world to agree to this, > as I expect more talking here on NANOG than action around this issue. > But I'd be happy to join and support such a cabal, with the backing of > my own management toward making this commitment, at least from an > African standpoint. > If the Telecom Infra Project <https://telecominfraproject.com/participants/> is a good indicator of what operators can achieve by uniting, then you're on a good trajectory. Cheers, Etienne On Wed, Sep 8, 2021 at 9:25 AM Mark Tinka wrote: > > > On 9/8/21 08:50, Saku Ytti wrote: > > > Fully agreed, I just don't see the driver. But I can imagine a > > different timeline where in 2000 several tier1 signed mutual binding > > contracts to drop IPv4 at the edge in 2020. And no one opposed, > > because 20 years before was 1980, and 20 years in the future IPv4 > > wont' anymore be a thing, it's clear due to exponential growth. > > > > And we'd all be enjoying a much simplified stack and lower costs all > > around (vendor, us, customers). > > > > Why is this not possible now? Why would we not sign this mutual > > agreement for 2040? Otherwise we'll be having this same discussion in > > 2040. > > I do not see why this is not possible now. > > In fact, I'd go as far as saying that the proposal should be shortened > from 20 years to 10 years from today. 10 years is not unreasonable. > > I'm not sure if there needs to be a separate "cabal" amongst the major > network operators that cover every corner of the world to agree to this, > as I expect more talking here on NANOG than action around this issue. > But I'd be happy to join and support such a cabal, with the backing of > my own management toward making this commitment, at least from an > African standpoint. > > I know at least 3 or 4 other operators in Africa that would be willing > to commit to the same, either directly or by proxy with us. > > Do we drive this through the IETF, or just have private, multi-lateral > agreements, as major operators? > > I'm now just thinking of how we get this idea off the ground, and stop > talking too much. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: The great Netflix vpn debacle! (geofeeds)
I got a bit carried away watching that :) Yes, it looks like that's what I'm referring to. With me, my muse often sings well when I'm doodling. The problem is that I sometimes want to return to the doodle, which becomes problematic when you're sharing a classical whiteboard. Cheers, Etienne On Fri, Sep 3, 2021 at 5:35 PM Mark Tinka wrote: > > > On 9/3/21 17:29, Etienne-Victor Depasquale wrote: > > I've been mulling over the use of an interactive whiteboard - > > not just for the "screen real estate", > > as you so correctly put it, > > but also to save my doodles. > > It beats hogging whiteboards. > > Has anyone tried this? > > You mean like this one he is using in the video? > > https://www.youtube.com/watch?v=IwxapMyPZe0 > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: The great Netflix vpn debacle! (geofeeds)
I've been mulling over the use of an interactive whiteboard - not just for the "screen real estate", as you so correctly put it, but also to save my doodles. It beats hogging whiteboards. Has anyone tried this? On Fri, Sep 3, 2021 at 5:19 PM Mark Tinka wrote: > > > On 9/3/21 17:07, Stephen Satchell wrote: > > > > > Size matters, too. For example, I have a 54" screen. My record is > > twelve open (tiled) code windows. Usually, I have three or four code > > windows and a LibreWriter window with the specifiations and requirements. > > Okay - "screen real estate" :-). > > Mark. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Telecommunications network drafting software
Folks, thanks for the pointers; much appreciated. OmniGraffle seems to have some traction. Perhaps I haven't done Visio justice, as I've received a few pointers that way too. What I can add to my original post is that to date, I've found that the stencils with the broadest scope are those from Cisco. The Cisco stencils include product genre as well as product-specific icons. The others I have, like the ones from APC and IBM, are almost wholly product-oriented. Cheers, Etienne On Thu, Sep 2, 2021 at 8:26 AM Måns Nilsson wrote: > Subject: Re: Telecommunications network drafting software Date: Wed, Sep > 01, 2021 at 03:26:08PM -0400 Quoting Eric Kuhnke (eric.kuh...@gmail.com): > > For logical diagrams of networks, on MacOS, I recommend Omnigraffle. > > OmniGraffle is what Visio would be if Visio was cool, looked good and > didn't hate its users. Only drawback -- to some -- is that it's OS X only. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR+46 705 989668 > ... I think I'd better go back to my DESK and toy with a few common > MISAPPREHENSIONS ... > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Telecommunications network drafting software
Hello folks, Would you care to share some pointers to drafting software which you use to draw up architectural drafts (for telecoms networks, including cable operators' networks) ? I've found Visio to be a bit weak in this respect, even after adding third party stencils. One product I'm exploring is ConceptDraw's "diagram" product, but I'd like to hear about anything you can share with me. Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Tools and procedure for Network testing
Ah no, Humberto, I wasn't offended ! You're perfectly entitled to choices (as if you needed my saying so :) ) and I just wanted to learn more about what criteria drive your preferences. Thank you for replying. Cheers, Etienne On Thu, Aug 26, 2021 at 8:23 PM Humberto Galiza wrote: > Sorry if you thought so Etienne, but I didn't mean to 'suggest' it as > a second-class/second option solution (please note I only mentioned > cost and open source as the factors; I'm sure there are much more to > evaluate!). I just put the options on the table willing to help him to > see what's available out there. It is up to him now to pick X, Y, or > go with ping -i. > > This list is really become more and more sensitive these days :p > > On Thu, Aug 26, 2021 at 7:05 PM Etienne-Victor Depasquale > wrote: > > > > > >> If the budget is short or if you're willing to go with an open source > >> suite for testing, you might want to have a look at Pktgen-DPDK too: > >> https://github.com/pktgen/Pktgen-DPDK > >> There are tons of tutorials out there explaining how to use Linux + > >> pktgen-dpdk to generate traffic. I hope it helps. > > > > > > Without wishing in the least to derail this thread, > > would you explain why you (seem to) consider Pktgen-DPDK > > as a second, rather than a first choice, > > for packet generation? > > > > Cheers, > > > > Etienne > > > > On Thu, Aug 26, 2021 at 7:59 PM Humberto Galiza < > humbertogal...@gmail.com> wrote: > >> > >> I've used Ixia for similar purposes (nothing related to voip stuff > >> though), but as others already said equipment cost is a factor here. > >> If the budget is short or if you're willing to go with an open source > >> suite for testing, you might want to have a look at Pktgen-DPDK too: > >> https://github.com/pktgen/Pktgen-DPDK > >> There are tons of tutorials out there explaining how to use Linux + > >> pktgen-dpdk to generate traffic. I hope it helps. > >> > >> Cheers! > >> > >> On Thu, Aug 26, 2021 at 2:07 PM Joe Yabuki > wrote: > >> > > >> > Hi all, > >> > > >> > I just wanted to know how you do your network testing when validating > a new design/technology in your Network, especially to ensure that it will > meet your SLA requirements for example that a voice call will not be > dropped in case of a network element failure ? > >> > > >> > Do you test with IXIA, multiping, launch somes VM using ping with -i > option, Windows ping by setting the timeout interval, or may be directly > from the Network device (routers...), > >> > > >> > Many thanks, > >> > Joe > > > > > > > > -- > > Ing. Etienne-Victor Depasquale > > Assistant Lecturer > > Department of Communications & Computer Engineering > > Faculty of Information & Communication Technology > > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Tools and procedure for Network testing
> If the budget is short or if you're willing to go with an open source > suite for testing, you might want to have a look at Pktgen-DPDK too: > https://github.com/pktgen/Pktgen-DPDK > There are tons of tutorials out there explaining how to use Linux + > pktgen-dpdk to generate traffic. I hope it helps. > Without wishing in the least to derail this thread, would you explain why you (seem to) consider Pktgen-DPDK as a second, rather than a first choice, for packet generation? Cheers, Etienne On Thu, Aug 26, 2021 at 7:59 PM Humberto Galiza wrote: > I've used Ixia for similar purposes (nothing related to voip stuff > though), but as others already said equipment cost is a factor here. > If the budget is short or if you're willing to go with an open source > suite for testing, you might want to have a look at Pktgen-DPDK too: > https://github.com/pktgen/Pktgen-DPDK > There are tons of tutorials out there explaining how to use Linux + > pktgen-dpdk to generate traffic. I hope it helps. > > Cheers! > > On Thu, Aug 26, 2021 at 2:07 PM Joe Yabuki wrote: > > > > Hi all, > > > > I just wanted to know how you do your network testing when validating a > new design/technology in your Network, especially to ensure that it will > meet your SLA requirements for example that a voice call will not be > dropped in case of a network element failure ? > > > > Do you test with IXIA, multiping, launch somes VM using ping with -i > option, Windows ping by setting the timeout interval, or may be directly > from the Network device (routers...), > > > > Many thanks, > > Joe > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Call for academic researchers (Re: New minimum speed for US broadband connections)
Sean, I can send you tens (10s) of papers on research into QoE for streaming media; some of them form the basis of my own current research, i.e. I'm depending on their validity for my own work to be valid. At this moment in time, I'm unable to digest it for you as it's been a while since I read it. I can offer to: (a) (privately) send the above-mentioned collection of papers, (b) offer you a digest later this year, most likely around September, and (c) point out one core point, which is that there's a concept of "sustainable bandwidth" that's the determinant of good QoE. I concede that "sustainable bandwidth" needs explanation, which I can't accurately describe at the moment either. Let me know whether any of the above offers interests you. Cheers, Etienne On Sun, May 30, 2021 at 1:28 AM Sean Donelan wrote: > > I thought in the 1990s, we had moved beyond using average bps measurements > for IP congestion collapse. During the peering battles, some ISPs used to > claim average bps measurements showed no problems. But in reality there > were massive packet drops, re-transmits and congestive collapse which > didn't show up in simple average bps graphs. > > > Have any academic researchers done work on what are the real-world minimum > connection requirements for home-schooling, video teams applications, job > interview video calls, and network background application noise? > > > During the last year, I've been providing volunteer pandemic home > schooling support for a few primary school teachers in a couple of > different states. Its been tough for pupils on lifeline service (fixed > or mobile), and some pupils were never reached. I found lifeline students > on mobile (i.e. 3G speeds) had trouble using even audio-only group calls, > and the exam proctoring apps often didn't work at all forcing those > students to fail exams unnecessarily. > > In my experience, anecdotal data need some academic researchers, pupils > with at least 5 mbps (real-world measurement) upstream connections at > home didn't seem to have those problems, even though the average bps graph > was less than 1 mbps. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
Sure, here goes: https://www.surveymonkey.com/results/SM-BJ9FCT6K9/ Cheers, Etienne On Fri, Mar 5, 2021 at 5:06 PM Tom Hill wrote: > On 04/03/2021 18:20, Etienne-Victor Depasquale wrote: > > *SECTION 2: Survey results* > > I don't see the embedded images, and there's no way to show them inline. > For the sake of simplicity/sharing, are these results presented anywhere > on a web page? :) > > Regards, > > -- > Tom > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
dia, vol. 24, no. 3, pp. 38–47, 2017, ISSN: 1941-0166. DOI: 10.1109/MMUL.2017.3051514. [3] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards Power Efficient High Performance Packet I/O,” IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 4, pp. 981–996, April 2020, ISSN:1558-2183. DOI: 10.1109/TPDS.2019.2957746. [4] G. Li, D. Zhang, Y. Li, and K. Li, “Toward energy efficiency optimization of pktgen-DPDK for green network testbeds,” China Communications, vol. 15, no. 11, pp. 199–207, November 2018, ISSN: 1673-5447. DOI: 10.1109/CC.2018.8543100. On Sat, Feb 27, 2021 at 5:11 PM Etienne-Victor Depasquale wrote: > Just a quick note to say that I've closed the survey. > > I haven't published the results yet as I said that I would write notes > necessary as a preamble to correctly inform potential readers, > and these notes are taking longer to write than I have time available. > > Cheers, > > Etienne > > On Wed, Feb 24, 2021 at 7:07 PM Etienne-Victor Depasquale > wrote: > >> I think I need to calm this thread down. >> >> I'm a researcher, and my interest is in the truth, not in my opinion. >> >> I've read some facts in this thread that are necessary >> as a prerequisite to the publication of the results on Friday. >> >> I do want to ensure that no future reader is misinformed and will do my >> best, >> with the help of contribution from my peers in this good community, >> to summarize all objections to this survey's questions, >> in the same message as that which publishes the result. >> >> All peace and good wishes, >> >> Etienne >> >> On Wed, Feb 24, 2021 at 4:35 PM Robert Bays wrote: >> >>> To the nanog community, I’m sorry to have dragged this conversation out >>> further. I'm only responding to this because there are a significant >>> number of open source projects and commercial products that use DPDK, or >>> similar userspace network environment in their implementations. The >>> statements in this thread incorrectly cast them, because they use DPDK, as >>> inefficient. But the reality is they have all been designed from day one >>> not to unnecessarily consume power. Please ask your open source dev and/or >>> vendor of choice to verify. But please don’t rely on the information in >>> this thread to make decisions about what you deploy in your network. >>> >>> On Feb 23, 2021, at 11:44 PM, Etienne-Victor Depasquale >>> wrote: >>> >>> Hello Robert, >>> >>> Your statement that DPDK “keeps utilization at 100% regardless of packet >>>> activity” is just not correct. You further pre-suppose "widespread DPDK's >>>> core operating inefficiency” without any data to backup the operating >>>> inefficacy assertion. >>>> >>> >>> This statement is incorrect. >>> I have provided references (please see earlier e-mails) that investigate >>> the operation of DPDK. >>> These references are items of peer-reviewed research that investigate a >>> perceived problem with deployment of DPDK. >>> If the power consumption incurred while running DPDK were a corner case, >>> then there would be little to no research value in investigating such >>> behavior. >>> >>> >>> Your references don’t take into account the code that this community >>> would actually deploy; open source implementations like DANOS, FD.io, >>> or OVS. They don’t audit any commercial products that implement userspace >>> stacks. None of your references say that DPDK is inherently inefficient. >>> The closest they come is to say that tight polling is inefficient. But >>> tight polling, even in the earliest days of DPDK, was never meant to be a >>> design pattern that was actually deployed into production. I was there for >>> those early conversations. >>> >>> Please don’t mislead the community into believing that DPDK == power bad >>>> >>> I have to object to this statement. It does seem to imply malice, or, at >>> best, amateurish behaviour, whether you intended it or not. >>> >>> >>> Object all you want. You are misleading people with your comments. And >>> in the process you are denigrating a large swath of OSS projects and >>> commercial products that use DPDK. Your survey questions are leading and >>> provide a false dichotomy. And when you post the results here, they will >>> be archived forever to continue to spread misinformation, unfortunately. >>>
Re: DPDK and energy efficiency
Just a quick note to say that I've closed the survey. I haven't published the results yet as I said that I would write notes necessary as a preamble to correctly inform potential readers, and these notes are taking longer to write than I have time available. Cheers, Etienne On Wed, Feb 24, 2021 at 7:07 PM Etienne-Victor Depasquale wrote: > I think I need to calm this thread down. > > I'm a researcher, and my interest is in the truth, not in my opinion. > > I've read some facts in this thread that are necessary > as a prerequisite to the publication of the results on Friday. > > I do want to ensure that no future reader is misinformed and will do my > best, > with the help of contribution from my peers in this good community, > to summarize all objections to this survey's questions, > in the same message as that which publishes the result. > > All peace and good wishes, > > Etienne > > On Wed, Feb 24, 2021 at 4:35 PM Robert Bays wrote: > >> To the nanog community, I’m sorry to have dragged this conversation out >> further. I'm only responding to this because there are a significant >> number of open source projects and commercial products that use DPDK, or >> similar userspace network environment in their implementations. The >> statements in this thread incorrectly cast them, because they use DPDK, as >> inefficient. But the reality is they have all been designed from day one >> not to unnecessarily consume power. Please ask your open source dev and/or >> vendor of choice to verify. But please don’t rely on the information in >> this thread to make decisions about what you deploy in your network. >> >> On Feb 23, 2021, at 11:44 PM, Etienne-Victor Depasquale >> wrote: >> >> Hello Robert, >> >> Your statement that DPDK “keeps utilization at 100% regardless of packet >>> activity” is just not correct. You further pre-suppose "widespread DPDK's >>> core operating inefficiency” without any data to backup the operating >>> inefficacy assertion. >>> >> >> This statement is incorrect. >> I have provided references (please see earlier e-mails) that investigate >> the operation of DPDK. >> These references are items of peer-reviewed research that investigate a >> perceived problem with deployment of DPDK. >> If the power consumption incurred while running DPDK were a corner case, >> then there would be little to no research value in investigating such >> behavior. >> >> >> Your references don’t take into account the code that this community >> would actually deploy; open source implementations like DANOS, FD.io, or >> OVS. They don’t audit any commercial products that implement userspace >> stacks. None of your references say that DPDK is inherently inefficient. >> The closest they come is to say that tight polling is inefficient. But >> tight polling, even in the earliest days of DPDK, was never meant to be a >> design pattern that was actually deployed into production. I was there for >> those early conversations. >> >> Please don’t mislead the community into believing that DPDK == power bad >>> >> I have to object to this statement. It does seem to imply malice, or, at >> best, amateurish behaviour, whether you intended it or not. >> >> >> Object all you want. You are misleading people with your comments. And >> in the process you are denigrating a large swath of OSS projects and >> commercial products that use DPDK. Your survey questions are leading and >> provide a false dichotomy. And when you post the results here, they will >> be archived forever to continue to spread misinformation, unfortunately. >> >> Everything following is informational. Stop here if so inclined. >>> >> Please stop delving into the detail of DPDK's facilities without regard >> for your logical omission: >> that whether the facilities are available or not, DPDK's deployment >> profile (meaning: how it's being used in general), as indicated by the >> references I've provided, >> are leading to high power inefficiency on cores partitioned to the data >> plane. >> >> >> I’ve been writing network appliance code for over 20 years. I designed >> network architectures for years before that. I have 10s of thousands of >> DPDK based appliances in production at this moment across multiple >> different use cases. I work with companies that have 100s of thousands of >> units in production that leverage userspace runtimes. I do think I >> understand DPDK’s deployment profile
Re: DPDK and energy efficiency
I think I need to calm this thread down. I'm a researcher, and my interest is in the truth, not in my opinion. I've read some facts in this thread that are necessary as a prerequisite to the publication of the results on Friday. I do want to ensure that no future reader is misinformed and will do my best, with the help of contribution from my peers in this good community, to summarize all objections to this survey's questions, in the same message as that which publishes the result. All peace and good wishes, Etienne On Wed, Feb 24, 2021 at 4:35 PM Robert Bays wrote: > To the nanog community, I’m sorry to have dragged this conversation out > further. I'm only responding to this because there are a significant > number of open source projects and commercial products that use DPDK, or > similar userspace network environment in their implementations. The > statements in this thread incorrectly cast them, because they use DPDK, as > inefficient. But the reality is they have all been designed from day one > not to unnecessarily consume power. Please ask your open source dev and/or > vendor of choice to verify. But please don’t rely on the information in > this thread to make decisions about what you deploy in your network. > > On Feb 23, 2021, at 11:44 PM, Etienne-Victor Depasquale > wrote: > > Hello Robert, > > Your statement that DPDK “keeps utilization at 100% regardless of packet >> activity” is just not correct. You further pre-suppose "widespread DPDK's >> core operating inefficiency” without any data to backup the operating >> inefficacy assertion. >> > > This statement is incorrect. > I have provided references (please see earlier e-mails) that investigate > the operation of DPDK. > These references are items of peer-reviewed research that investigate a > perceived problem with deployment of DPDK. > If the power consumption incurred while running DPDK were a corner case, > then there would be little to no research value in investigating such > behavior. > > > Your references don’t take into account the code that this community would > actually deploy; open source implementations like DANOS, FD.io, or OVS. > They don’t audit any commercial products that implement userspace stacks. > None of your references say that DPDK is inherently inefficient. The > closest they come is to say that tight polling is inefficient. But tight > polling, even in the earliest days of DPDK, was never meant to be a design > pattern that was actually deployed into production. I was there for those > early conversations. > > Please don’t mislead the community into believing that DPDK == power bad >> > I have to object to this statement. It does seem to imply malice, or, at > best, amateurish behaviour, whether you intended it or not. > > > Object all you want. You are misleading people with your comments. And > in the process you are denigrating a large swath of OSS projects and > commercial products that use DPDK. Your survey questions are leading and > provide a false dichotomy. And when you post the results here, they will > be archived forever to continue to spread misinformation, unfortunately. > > Everything following is informational. Stop here if so inclined. >> > Please stop delving into the detail of DPDK's facilities without regard > for your logical omission: > that whether the facilities are available or not, DPDK's deployment > profile (meaning: how it's being used in general), as indicated by the > references I've provided, > are leading to high power inefficiency on cores partitioned to the data > plane. > > > I’ve been writing network appliance code for over 20 years. I designed > network architectures for years before that. I have 10s of thousands of > DPDK based appliances in production at this moment across multiple > different use cases. I work with companies that have 100s of thousands of > units in production that leverage userspace runtimes. I do think I > understand DPDK’s deployment profile better than you. That’s what I have > been trying to tell you. People don’t write inefficient DPDK code to put > into production. We’re not dumb. We’ve been thinking about power > consumption from day one. DPDK was never supposed to be just a tight loop > poll. You were always supposed to put in the very minimal extra work to > modulate power consumption. > > The takeaway is that DPDK (and similar) doesn’t guarantee runaway power >> bills. >> > Of course it doesn't. > Even the second question of that bare-bones survey tried to communicate > this much. > > If you have questions, I’d be happy to discuss off line >> > I would be happy to answer your objec
Re: DPDK and energy efficiency
Hello Robert, Your statement that DPDK “keeps utilization at 100% regardless of packet > activity” is just not correct. You further pre-suppose "widespread DPDK's > core operating inefficiency” without any data to backup the operating > inefficacy assertion. > This statement is incorrect. I have provided references (please see earlier e-mails) that investigate the operation of DPDK. These references are items of peer-reviewed research that investigate a perceived problem with deployment of DPDK. If the power consumption incurred while running DPDK were a corner case, then there would be little to no research value in investigating such behavior. Please don’t mislead the community into believing that DPDK == power bad > I have to object to this statement. It does seem to imply malice, or, at best, amateurish behaviour, whether you intended it or not. Everything following is informational. Stop here if so inclined. > Please stop delving into the detail of DPDK's facilities without regard for your logical omission: that whether the facilities are available or not, DPDK's deployment profile (meaning: how it's being used in general), as indicated by the references I've provided, are leading to high power inefficiency on cores partitioned to the data plane. The takeaway is that DPDK (and similar) doesn’t guarantee runaway power > bills. > Of course it doesn't. Even the second question of that bare-bones survey tried to communicate this much. If you have questions, I’d be happy to discuss off line > I would be happy to answer your objections in detail off line too. Just let me know. Cheers, Etienne On Wed, Feb 24, 2021 at 12:12 AM Robert Bays wrote: > Hi Etienne, > > Your statement that DPDK “keeps utilization at 100% regardless of packet > activity” is just not correct. You further pre-suppose "widespread DPDK's > core operating inefficiency” without any data to backup the operating > inefficacy assertion. Your statements, taken at face value, lead people to > believe that if a project uses DPDK it’s going to increase their power > costs. And that’s just not the case. Please don’t mislead the community > into believing that DPDK == power bad. > > Everything following is informational. Stop here if so inclined. > > DPDK does not dictate CPU utilization or power consumption, the > application leveraging DPDK does. It’s the application that decides how to > poll packets. If an application implements DPDK using only a tight polling > loop, then it will keep CPU cores that are running DPDK threads at 100%. > But only the most simple and/or bespoke (think trading) applications are > implemented this way. You don’t need tight polling all the time to get the > performance gains provided by DPDK or similar environments. The vast > majority of applications that this audience would actually install in their > networks do not do tight polling all the time and therefore don’t consume > 100% of the CPU all the time. An interesting, helpful research effort you > could lead would be to survey the ecosystem to catalog those applications > that do fall into the power hungry category and help them to change their > code. > > Intel DPDK application development guidelines don’t pre-suppose tight > polling all the time and offer at least two methods for optimizing power > against throughput. The older method is to use adaptive polling; > increasing the polling frequency as traffic load increases. This keeps cpu > utilization low when packet load is light and increases it as traffic > levels warrant. The second method is to use P-states and/or C-states to > put the processor into lower power modes when traffic loads are lighter. > We have found that adaptive polling works better across a larger pool of > hardware types, and therefore that is what DANOS uses, amongst other > things. > > Further, performance and power consumption are dictated by a multivariate > set of application decisions including: design patterns such as single > thread run to completion models vs. passing mbufs between multiple threads, > buffer sizes and cache management algorithms, combining and/or separating > tx/rx threads, binding threads to specific lcores, reserved cores for DPDK > threads, hyperthreading, kernel schedulers, hypervisor schedulers, > interface drivers, etc. All of these are application specific, not DPDK > generic. Well written applications that leverage DPDK provide knobs for > the user to tune these settings for their specific environment and use > case. None of this unique to DPDK. Solution designs were cribbed from > previous technologies. > > The takeaway is that DPDK (and similar) doesn’t guarantee runaway power > bills. Power consumption is dictated by the application.
Re: DPDK and energy efficiency
> > This is way too deep in the weeds of developing with the DPDK > libraries for your audience here to have much in the way of useful > comment. This is an operators group. > Fair enough, and thank you for stepping on the brakes :) Honestly, I didn't intend to get embroiled in this. The questions were bare-bones and relate to common use of DPDK. Over and out. I'll post the results on Friday evening CET. Cheers, Etienne On Tue, Feb 23, 2021 at 11:38 PM William Herrin wrote: > On Tue, Feb 23, 2021 at 2:22 PM Etienne-Victor Depasquale > wrote: > >> DPDK doesn't inherently do much in the way of power management. > > > > I agree - it doesn't. That's not what it was made for. > > > >> Note that DPDK applications are usually intended to run in very-high > > > > data rate environments where no gains are likely to be realized by > > avoiding a busy-wait loop. > > > > That's not what research shows. > > > > Use of LPI states is proposed for power management under high data rate > conditions in [5] and > > in [6], use of the low-power instruction halt is investigated and found > to save power under such conditions. > > Howdy, > > This is way too deep in the weeds of developing with the DPDK > libraries for your audience here to have much in the way of useful > comment. This is an operators group. > > If anyone is interested, the techniques DPDK offers application > authors to manage power on the dataplane cores are described here: > > https://doc.dpdk.org/guides/prog_guide/power_man.html > > The main thing devs do, since it's easy, is add a call to rte_pause() > in any empty polling loop. IIRC, that just calls the CPU PAUSE > instruction which doesn't actually pause anything but saves a little > power by de-pipelining and, if hyperthreading is enabled, releasing > the core to run the alternate thread. > > Regards, > Bill Herrin > > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
>
> This comes from OVS code and shows OVS thread spinning, not DPDK PMD.
> Blame the OVS application for not using e.g. _mm_pause() and burning
> the CPU like crazy.
>
OK, I'm citing a bit more from the same reference:
*"By tracing back to the function’s caller *
*in the PMD thread main(void *f_), *
we found that the thread kept spinning on the following code block:
for ( ; ; ) {
for ( i = 0; i < poll_cnt; i ++) {
dp_netdev_process_rxq_port (pmd, list[i].port, poll_list[i].rx) ;
}
}
This indicates that the [PMD] thread was continuously
monitoring and executing the receiving data path."
Cheers,
Etienne
On Tue, Feb 23, 2021 at 10:33 PM Pawel Malachowski <
pawmal-na...@freebsd.lublin.pl> wrote:
> > > No, it is not PMD that runs the processor in a polling loop.
> > > It is the application itself, thay may or may not busy loop,
> > > depending on application programmers choice.
> >
> > From one of my earlier references [2]:
> >
> > "we found that a poll mode driver (PMD)
> > thread accounted for approximately 99.7 percent
> > CPU occupancy (a full core utilization)."
> >
> > And further on:
> >
> > "we found that the thread kept spinning on the following code block:
> >
> > *for ( ; ; ) {for ( i = 0; i < poll_cnt; i ++)
> {dp_netdev_process_rxq_port
> > (pmd, list[i].port, poll_list[i].rx) ;}}*
> > This indicates that the thread was continuously
> > monitoring and executing the receiving data path."
>
> This comes from OVS code and shows OVS thread spinning, not DPDK PMD.
> Blame the OVS application for not using e.g. _mm_pause() and burning
> the CPU like crazy.
>
>
> For comparison, take a look at top+i7z output from DPDK-based 100G DDoS
> scrubber currently lifting some low traffic using cores 1-13 on 16 core
> host. It uses naive DPDK::rte_pause() throttling to enter C1.
>
> Tasks: 342 total, 1 running, 195 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 6.6 us, 0.6 sy, 0.0 ni, 89.7 id, 3.1 wa, 0.0 hi, 0.0 si,
> 0.0 st
>
> Core [core-id] :Actual Freq (Mult.) C0% Halt(C1)% C3 %
> C6 % Temp VCore
> Core 1 [0]: 1467.73 (14.68x) 2.155.35 1
> 92.343 0.6724
> Core 2 [1]: 1201.09 (12.01x) 11.793.9 0
> 039 0.6575
> Core 3 [2]: 1200.06 (12.00x) 11.893.8 0
> 042 0.6543
> Core 4 [3]: 1200.14 (12.00x) 11.893.8 0
> 041 0.6549
> Core 5 [4]: 1200.10 (12.00x) 11.893.8 0
> 041 0.6526
> Core 6 [5]: 1200.12 (12.00x) 11.893.8 0
> 040 0.6559
> Core 7 [6]: 1201.01 (12.01x) 11.893.8 0
> 041 0.6559
> Core 8 [7]: 1201.02 (12.01x) 11.893.8 0
> 043 0.6525
> Core 9 [8]: 1201.00 (12.01x) 11.893.8 0
> 041 0.6857
> Core 10 [9]: 1201.04 (12.01x) 11.893.8 0
> 040 0.6541
> Core 11 [10]: 1201.95 (12.02x) 13.692.9 0
> 040 0.6558
> Core 12 [11]: 1201.02 (12.01x) 11.893.8 0
> 042 0.6526
> Core 13 [12]: 1204.97 (12.05x) 17.690.8 0
> 045 0.6814
> Core 14 [13]: 1248.39 (12.48x) 28.284.7 0
> 041 0.6855
> Core 15 [14]: 2790.74 (27.91x) 91.9 0 1
> 141 0.8885 <-- not PMD
> Core 16 [15]: 1262.29 (12.62x) 13.134.9 1.7
> 56.243 0.6616
>
> $ dataplanectl stats fcore | grep total
> fcore total idle 393788223887 work 860443658 (0.2%) (forced-idle
> 7458486526622) recv 202201388561 drop 61259353721 (30.3%) limit 269909758
> (0.1%) pass 140606076622 (69.6%) ingress 66048460 (0.0%/0.0%) sent
> 162580376914 (80.4%/100.0%) overflow 0 (0.0%) sampled 628488188/628488188
>
>
>
> --
> Pawel Malachowski
> @pawmal80
>
--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
Oh dear ... instead of "and in [6]", I should have written "and in [3]". On Tue, Feb 23, 2021 at 11:21 PM Etienne-Victor Depasquale wrote: > DPDK doesn't inherently do much in the way of power management. >> > I agree - it doesn't. That's not what it was made for. > > Note that DPDK applications are usually intended to run in very-high > > data rate environments where no gains are likely to be realized by > avoiding a busy-wait loop. > > That's not what research shows. > > Use of LPI states is proposed for power management under high data rate > conditions in [5] and > in [6], use of the low-power instruction *halt * is investigated and > found to save power under such conditions. > > Cheers, > > Etienne > > [3] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards Power > Efficient High Performance Packet I/O,” > IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 4, pp. > 981–996, April 2020, > ISSN:1558-2183. DOI: 10.1109/TPDS.2019.2957746 > > [5] R. Bolla, R. Bruschi, F. Davoli, and J. F. Pajo, “A Model-Based > Approach Towards Real-Time Analytics in NFV Infrastructures,” > IEEE Transactions on Green Communications and Networking, vol. 4, no. 2, > pp. 529–541, Jun. 2020, ISSN: 2473-2400. > DOI: 10.1109/TGCN.2019.2961192. > > > On Tue, Feb 23, 2021 at 11:04 PM William Herrin wrote: > >> On Mon, Feb 22, 2021 at 11:24 PM Etienne-Victor Depasquale >> wrote: >> >> >> >> Beyond RX/TX CPU affinity, in DANOS you can further tune power >> consumption by changing the adaptive polling rate. It doesn’t, per the >> survey, "keep utilization at 100% regardless of packet activity.” >> > >> > Robert, you seem to be conflating DPDK >> > with DANOS' power control algorithms that modulate DPDK's default >> behaviour. >> > Keep in mind that this is a bare-bones survey intended for busy, >> knowledgeable people (the ones you'd find on NANOG) - >> >> Hi, >> >> Since you understand that, I'm not really clear what you're asking in >> the survey. >> >> DPDK doesn't inherently do much in the way of power management. The >> polling loops are in the application side of the software, not the >> DPDK libraries or NIC driver. It's up to the application author to >> decide to detect idleness in the polling loop and take action to >> reduce CPU load. If they go for a simple busy-wait, the dataplane >> cores run at 100% all the time regardless of packet load. This has the >> expected impact on the server's power consumption. >> >> Note that DPDK applications are usually intended to run in very-high >> data rate environments where no gains are likely to be realized by >> avoiding a busy-wait loop. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin >> b...@herrin.us >> https://bill.herrin.us/ >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
> > DPDK doesn't inherently do much in the way of power management. > I agree - it doesn't. That's not what it was made for. Note that DPDK applications are usually intended to run in very-high data rate environments where no gains are likely to be realized by avoiding a busy-wait loop. That's not what research shows. Use of LPI states is proposed for power management under high data rate conditions in [5] and in [6], use of the low-power instruction *halt * is investigated and found to save power under such conditions. Cheers, Etienne [3] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards Power Efficient High Performance Packet I/O,” IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 4, pp. 981–996, April 2020, ISSN:1558-2183. DOI: 10.1109/TPDS.2019.2957746 [5] R. Bolla, R. Bruschi, F. Davoli, and J. F. Pajo, “A Model-Based Approach Towards Real-Time Analytics in NFV Infrastructures,” IEEE Transactions on Green Communications and Networking, vol. 4, no. 2, pp. 529–541, Jun. 2020, ISSN: 2473-2400. DOI: 10.1109/TGCN.2019.2961192. On Tue, Feb 23, 2021 at 11:04 PM William Herrin wrote: > On Mon, Feb 22, 2021 at 11:24 PM Etienne-Victor Depasquale > wrote: > >> > >> Beyond RX/TX CPU affinity, in DANOS you can further tune power > consumption by changing the adaptive polling rate. It doesn’t, per the > survey, "keep utilization at 100% regardless of packet activity.” > > > > Robert, you seem to be conflating DPDK > > with DANOS' power control algorithms that modulate DPDK's default > behaviour. > > Keep in mind that this is a bare-bones survey intended for busy, > knowledgeable people (the ones you'd find on NANOG) - > > Hi, > > Since you understand that, I'm not really clear what you're asking in > the survey. > > DPDK doesn't inherently do much in the way of power management. The > polling loops are in the application side of the software, not the > DPDK libraries or NIC driver. It's up to the application author to > decide to detect idleness in the polling loop and take action to > reduce CPU load. If they go for a simple busy-wait, the dataplane > cores run at 100% all the time regardless of packet load. This has the > expected impact on the server's power consumption. > > Note that DPDK applications are usually intended to run in very-high > data rate environments where no gains are likely to be realized by > avoiding a busy-wait loop. > > Regards, > Bill Herrin > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
> > Probably yeah. Have you assessed the lifetime cost of running a > multicore CPU at 100% vs at 10%, particularly as you're likely to have > multiples of these devices in operation? > Spot on. On Tue, Feb 23, 2021 at 6:07 PM Nick Hilliard wrote: > Shane Ronan wrote on 23/02/2021 16:59: > > For use cases where DPDK matters, are you really concerned with power > > consumption? > > Probably yeah. Have you assessed the lifetime cost of running a > multicore CPU at 100% vs at 10%, particularly as you're likely to have > multiples of these devices in operation? > > Nick > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
>
> No, it is not PMD that runs the processor in a polling loop.
> It is the application itself, thay may or may not busy loop,
> depending on application programmers choice.
>
>From one of my earlier references [2]:
"we found that a poll mode driver (PMD)
thread accounted for approximately 99.7 percent
CPU occupancy (a full core utilization)."
And further on:
"we found that the thread kept spinning on the following code block:
*for ( ; ; ) {for ( i = 0; i < poll_cnt; i ++) {dp_netdev_process_rxq_port
(pmd, list[i].port, poll_list[i].rx) ;}}*
This indicates that the thread was continuously
monitoring and executing the receiving data path."
[2] S. Fu, J. Liu, and W. Zhu, “Multimedia Content Delivery with Network
Function Virtualization: The Energy Perspective,”
IEEE MultiMedia, vol. 24, no. 3, pp. 38–47, 2017, ISSN: 1941-0166.
DOI: 10.1109/MMUL.2017.3051514.
On Tue, Feb 23, 2021 at 12:59 PM Pawel Malachowski <
pawmal-na...@freebsd.lublin.pl> wrote:
> Dnia Mon, Feb 22, 2021 at 12:45:52PM +0100, Etienne-Victor Depasquale
> napisał(a):
>
> > Every research paper I've read indicates that, regardless of whether it
> has
> > packets to process or not, DPDK PMDs (poll-mode drivers) prevent the CPU
> > from falling into an LPI (low-power idle).
> >
> > When it has no packets to process, the PMD runs the processor in a
> polling
> > loop that keeps utilization of the running core at 100%.
>
> No, it is not PMD that runs the processor in a polling loop.
> It is the application itself, thay may or may not busy loop,
> depending on application programmers choice.
>
>
> --
> Pawel Malachowski
> @pawmal80
>
--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
Sorry, last line should have been: "intended to get an impression of how widespread ***knowledge of*** DPDK's core operating inefficiency is", not: "intended to get an impression of how widespread DPDK's core operating inefficiency is" On Tue, Feb 23, 2021 at 8:22 AM Etienne-Victor Depasquale wrote: > Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption >> by changing the adaptive polling rate. It doesn’t, per the survey, "keep >> utilization at 100% regardless of packet activity.” >> > Robert, you seem to be conflating DPDK > with DANOS' power control algorithms that modulate DPDK's default > behaviour. > > Let me know what you think; otherwise, I'm pretty confident that DPDK does: > >> "keep utilization at 100% regardless of packet activity.” > > > Keep in mind that this is a bare-bones survey intended for busy, > knowledgeable people (the ones you'd find on NANOG) - > not a detailed breakdown of modes of operation of DPDK or DANOS. > DPDK has been designed for fast I/O that's unencumbered by the trappings > of general-purpose OSes, > and that's the impression that needs to be forefront. > Power control, as well as any other dimensions of modulation, > are detailed modes of operation that are well beyond the scope of a > bare-bones 2-question survey > intended to get an impression of how widespread DPDK's core operating > inefficiency is. > > Cheers, > > Etienne > > On Mon, Feb 22, 2021 at 10:20 PM Robert Bays wrote: > >> Beyond RX/TX CPU affinity, in DANOS you can further tune power >> consumption by changing the adaptive polling rate. It doesn’t, per the >> survey, "keep utilization at 100% regardless of packet activity.” Adaptive >> polling changes in DPDK optimize for tradeoffs between power consumption, >> latency/jitter and drops during throughput ramp up periods. Ideally your >> DPDK implementation has an algorithm that tries to automatically optimize >> based on current traffic patterns. >> >> In DANOS refer to the “system default dataplane power-profile” config >> command tree for adaptive polling settings. Interface RX/TX affinity is >> configured on a per interface basis under the “interfaces dataplane” config >> command tree. >> >> -robert >> >> >> > On Feb 22, 2021, at 11:46 AM, Jared Geiger wrote: >> > >> > DANOS lets you specify how many dataplane cores you use versus control >> plane cores. So if you put a 16 core host in to handle 2GB of traffic, you >> can adjust the dataplane worker cores as needed. Control plane cores don't >> stay at 100% utilization. >> > >> > I use that technique plus DANOS runs on VMware (not oversubscribed) >> which allows me to use the hardware for other VMs. NICS are attached to the >> VM via PCI Passthrough which helps eliminate the overhead to the VMware >> hypervisor itself. >> > >> > I have an 8 core VM with 4 cores set to dataplane and 4 to control >> plane. The 4 control plane cores are typically idle only processing BGP >> route updates, SNMP, logs, etc. >> > >> > ~Jared >> > >> > On Sun, Feb 21, 2021 at 11:30 PM Etienne-Victor Depasquale < >> ed...@ieee.org> wrote: >> > Hello folks, >> > >> > I've just followed a thread regarding use of CGNAT and noted a >> suggestion (regarding DANOS) that includes use of DPDK. >> > >> > As I'm interested in the breadth of adoption of DPDK, and as I'm a >> researcher into energy and power efficiency, I'd love to hear your feedback >> on your use of power consumption control by DPDK. >> > >> > I've drawn up a bare-bones, 2-question survey at this link: >> > >> > https://www.surveymonkey.com/r/J886DPY. >> > >> > Responses have been set to anonymous. >> > >> > Cheers, >> > >> > Etienne >> > >> > -- >> > Ing. Etienne-Victor Depasquale >> > Assistant Lecturer >> > Department of Communications & Computer Engineering >> > Faculty of Information & Communication Technology >> > University of Malta >> > Web. https://www.um.edu.mt/profile/etiennedepasquale >> >> > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
> > Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption > by changing the adaptive polling rate. It doesn’t, per the survey, "keep > utilization at 100% regardless of packet activity.” > Robert, you seem to be conflating DPDK with DANOS' power control algorithms that modulate DPDK's default behaviour. Let me know what you think; otherwise, I'm pretty confident that DPDK does: > "keep utilization at 100% regardless of packet activity.” Keep in mind that this is a bare-bones survey intended for busy, knowledgeable people (the ones you'd find on NANOG) - not a detailed breakdown of modes of operation of DPDK or DANOS. DPDK has been designed for fast I/O that's unencumbered by the trappings of general-purpose OSes, and that's the impression that needs to be forefront. Power control, as well as any other dimensions of modulation, are detailed modes of operation that are well beyond the scope of a bare-bones 2-question survey intended to get an impression of how widespread DPDK's core operating inefficiency is. Cheers, Etienne On Mon, Feb 22, 2021 at 10:20 PM Robert Bays wrote: > Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption > by changing the adaptive polling rate. It doesn’t, per the survey, "keep > utilization at 100% regardless of packet activity.” Adaptive polling > changes in DPDK optimize for tradeoffs between power consumption, > latency/jitter and drops during throughput ramp up periods. Ideally your > DPDK implementation has an algorithm that tries to automatically optimize > based on current traffic patterns. > > In DANOS refer to the “system default dataplane power-profile” config > command tree for adaptive polling settings. Interface RX/TX affinity is > configured on a per interface basis under the “interfaces dataplane” config > command tree. > > -robert > > > > On Feb 22, 2021, at 11:46 AM, Jared Geiger wrote: > > > > DANOS lets you specify how many dataplane cores you use versus control > plane cores. So if you put a 16 core host in to handle 2GB of traffic, you > can adjust the dataplane worker cores as needed. Control plane cores don't > stay at 100% utilization. > > > > I use that technique plus DANOS runs on VMware (not oversubscribed) > which allows me to use the hardware for other VMs. NICS are attached to the > VM via PCI Passthrough which helps eliminate the overhead to the VMware > hypervisor itself. > > > > I have an 8 core VM with 4 cores set to dataplane and 4 to control > plane. The 4 control plane cores are typically idle only processing BGP > route updates, SNMP, logs, etc. > > > > ~Jared > > > > On Sun, Feb 21, 2021 at 11:30 PM Etienne-Victor Depasquale < > ed...@ieee.org> wrote: > > Hello folks, > > > > I've just followed a thread regarding use of CGNAT and noted a > suggestion (regarding DANOS) that includes use of DPDK. > > > > As I'm interested in the breadth of adoption of DPDK, and as I'm a > researcher into energy and power efficiency, I'd love to hear your feedback > on your use of power consumption control by DPDK. > > > > I've drawn up a bare-bones, 2-question survey at this link: > > > > https://www.surveymonkey.com/r/J886DPY. > > > > Responses have been set to anonymous. > > > > Cheers, > > > > Etienne > > > > -- > > Ing. Etienne-Victor Depasquale > > Assistant Lecturer > > Department of Communications & Computer Engineering > > Faculty of Information & Communication Technology > > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
I forgot to point out that on Friday 26th, I'll share the results collected through a link or a series of screenshots. Cheers, Etienne On Mon, Feb 22, 2021 at 2:15 PM Pawel Malachowski < pawmal-na...@freebsd.lublin.pl> wrote: > Dnia Mon, Feb 22, 2021 at 01:01:45PM +0100, Etienne-Victor Depasquale > napisał(a): > > > It is, after all, Intel's response to the problem of general-purpose > > scheduling of its processors - which prevents the processor from being > > viable under high networking loads. > > It totally makes sense to busy poll under high networking load. > By high networking load I mean roughly > 7 Mpps RX+TX per one x86 CPU core. > > I partially agree it may be hard to mix DPDK and non-DPDK workload > on a single CPU, not only because of advanced power management logic > requirement for the dataplane application, but also due to LLC trashing. > It heavily depends on usecase and dataset sizes, for example > optimised FIB may fit nicely into cache and use only tiny, hot part > of the dataset, but CGNAT Mflow mapping likely won't fit. For such > a usecase I would recommand dedicated CPU or cache partitioning (CAT), > if available. > > In case of low volume traffic like 20-40G of IMIX one can dedicate > e.g. 2 cores and interleave busy polling with halt instructions to > lower the usage significantly (~60-80% core underutilisation). > > > > -- > Pawel Malachowski > @pawmal80 > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
> > It consumes 100% only if you busy poll (which is the default approach). > Precisely. It is, after all, Intel's response to the problem of general-purpose scheduling of its processors - which prevents the processor from being viable under high networking loads. Cheers, Etienne On Mon, Feb 22, 2021 at 12:58 PM Pawel Malachowski < pawmal-na...@freebsd.lublin.pl> wrote: > Dnia Mon, Feb 22, 2021 at 08:33:35AM -0300, Douglas Fischer napisał(a): > > > But IMHO, the questions do not cover the actual reality of DPDK. > > That característic of "100% CPU" depends on several aspects, like: > > - How old are the hardware on DPDK. > > - What type of DPDK Instructions are made(Very Dynamic as Statefull > CGNAT, > > ou Static ACLs?) > > - Using or not the measurements of DPDK Input/Drop/Fowarding. > > - CPU Affinity done according to the demand of traffic > > - SR-IOV (sharing resources) on DPDK. > > It consumes 100% only if you busy poll (which is the default approach). > One can switch between polling and interrupts (or monitor, if supported), > or introduce halt instructions, in case of low/medium traffic volume. > > > -- > Pawel Malachowski > @pawmal80 > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
Here are a few references. Strictly speaking, DPDK and SR-IOV are orthogonal. DPDK is intended to facilitate cloud-native operation through hardware independence. SR-IOV presumes SR-IOV-compliant hardware. [1] Z. Xu, F. Liu, T. Wang, and H. Xu, “Demystifying the energy efficiency of Network Function Virtualization,” in 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS), Jun. 2016, pp. 1–10. DOI: 10.1109/IWQoS.2016.7590429. [2] S. Fu, J. Liu, and W. Zhu, “Multimedia Content Delivery with Network Function Virtualization: The Energy Perspective,” IEEE MultiMedia, vol. 24, no. 3, pp. 38–47, 2017, ISSN: 1941-0166. DOI: 10.1109/MMUL.2017.3051514. [3] X. Li, W. Cheng, T. Zhang, F. Ren, and B. Yang, “Towards Power Efficient High Performance Packet I/O,” IEEE Transactions on Parallel and Distributed Systems, vol. 31, no. 4, pp. 981–996, April 2020, ISSN:1558-2183. DOI: 10.1109/TPDS.2019.2957746. [4] G. Li, D. Zhang, Y. Li, and K. Li, “Toward energy efficiency optimization of pktgen-DPDK for green network testbeds,” China Communications, vol. 15, no. 11, pp. 199–207, November 2018, ISSN: 1673-5447. DOI: 10.1109/CC.2018.8543100. On Mon, Feb 22, 2021 at 12:45 PM Etienne-Victor Depasquale wrote: > The way I saw, the questions induce the public to conclude that DPDK >> ALWAYS has 100% CPU usage, which is not true. > > > I don't concur. > > Every research paper I've read indicates that, regardless of whether it > has packets to process or not, DPDK PMDs (poll-mode drivers) prevent the > CPU from falling into an LPI (low-power idle). > > When it has no packets to process, the PMD runs the processor in a polling > loop that keeps utilization of the running core at 100%. > > Cheers, > > Etienne > > On Mon, Feb 22, 2021 at 12:33 PM Douglas Fischer > wrote: > >> I'm very happy to see interest in DPDK and power consumption. >> >> But IMHO, the questions do not cover the actual reality of DPDK. >> That característic of "100% CPU" depends on several aspects, like: >> - How old are the hardware on DPDK. >> - What type of DPDK Instructions are made(Very Dynamic as >> Statefull CGNAT, ou Static ACLs?) >> - Using or not the measurements of DPDK Input/Drop/Fowarding. >> - CPU Affinity done according to the demand of traffic >> - SR-IOV (sharing resources) on DPDK. >> >> The way I saw, the questions induce the public to conclude that DPDK >> ALWAYS has 100% CPU usage, which is not true. >> >> >> Em seg., 22 de fev. de 2021 às 04:30, Etienne-Victor Depasquale < >> ed...@ieee.org> escreveu: >> >>> Hello folks, >>> >>> I've just followed a thread regarding use of CGNAT and noted a >>> suggestion (regarding DANOS) that includes use of DPDK. >>> >>> As I'm interested in the breadth of adoption of DPDK, and as I'm a >>> researcher into energy and power efficiency, I'd love to hear your feedback >>> on your use of power consumption control by DPDK. >>> >>> I've drawn up a bare-bones, 2-question survey at this link: >>> >>> https://www.surveymonkey.com/r/J886DPY. >>> >>> Responses have been set to anonymous. >>> >>> Cheers, >>> >>> Etienne >>> >>> -- >>> Ing. Etienne-Victor Depasquale >>> Assistant Lecturer >>> Department of Communications & Computer Engineering >>> Faculty of Information & Communication Technology >>> University of Malta >>> Web. https://www.um.edu.mt/profile/etiennedepasquale >>> >> >> >> -- >> Douglas Fernando Fischer >> Engº de Controle e Automação >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: DPDK and energy efficiency
> > The way I saw, the questions induce the public to conclude that DPDK > ALWAYS has 100% CPU usage, which is not true. I don't concur. Every research paper I've read indicates that, regardless of whether it has packets to process or not, DPDK PMDs (poll-mode drivers) prevent the CPU from falling into an LPI (low-power idle). When it has no packets to process, the PMD runs the processor in a polling loop that keeps utilization of the running core at 100%. Cheers, Etienne On Mon, Feb 22, 2021 at 12:33 PM Douglas Fischer wrote: > I'm very happy to see interest in DPDK and power consumption. > > But IMHO, the questions do not cover the actual reality of DPDK. > That característic of "100% CPU" depends on several aspects, like: > - How old are the hardware on DPDK. > - What type of DPDK Instructions are made(Very Dynamic as > Statefull CGNAT, ou Static ACLs?) > - Using or not the measurements of DPDK Input/Drop/Fowarding. > - CPU Affinity done according to the demand of traffic > - SR-IOV (sharing resources) on DPDK. > > The way I saw, the questions induce the public to conclude that DPDK > ALWAYS has 100% CPU usage, which is not true. > > > Em seg., 22 de fev. de 2021 às 04:30, Etienne-Victor Depasquale < > ed...@ieee.org> escreveu: > >> Hello folks, >> >> I've just followed a thread regarding use of CGNAT and noted a suggestion >> (regarding DANOS) that includes use of DPDK. >> >> As I'm interested in the breadth of adoption of DPDK, and as I'm a >> researcher into energy and power efficiency, I'd love to hear your feedback >> on your use of power consumption control by DPDK. >> >> I've drawn up a bare-bones, 2-question survey at this link: >> >> https://www.surveymonkey.com/r/J886DPY. >> >> Responses have been set to anonymous. >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
DPDK and energy efficiency
Hello folks, I've just followed a thread regarding use of CGNAT and noted a suggestion (regarding DANOS) that includes use of DPDK. As I'm interested in the breadth of adoption of DPDK, and as I'm a researcher into energy and power efficiency, I'd love to hear your feedback on your use of power consumption control by DPDK. I've drawn up a bare-bones, 2-question survey at this link: https://www.surveymonkey.com/r/J886DPY. Responses have been set to anonymous. Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Follow up to "has virtualization become obsolete in 5G"?
> > I'm also unsure where it mentions that virtualization is now obsolete. > "Obsolete" was my term. The substance of my question last year was my surprise in observing what appeared to be a trend that virtualization technologies (KVM, Xen, Hyper-V ...) are no longer the first choice for implementation of network functions. Since then, every opportunity I've had to listen to operators, operators' groups, vendors and analysts has reaffirmed the preference of containerization technologies for implementation of network functions (NFs). What struck me in particular in the link I've shared is the extract I quoted: "Once the darling of the telecoms industry, NFV has had a rough ride in recent years and has even lead some industry observers to proclaim that NFV is dead." NFV solutions are moving to VM based deployments as a stop-gap and for the > future, towards micro-services built in containers. Agreed ... except that some "industry observers" may link NFV exclusively to virtualization technologies. I don't. However, in their favour, I'd dare say that it's not technically sound to blur the technical differences between NFs implemented in VMs and NFs implemented in containers. The term NFV is a bit of a stretch for what is really network-function-containerization. Cheers, Etienne On Sat, Jan 16, 2021 at 1:57 AM Laurent Dumont wrote: > The amount of buzzwords in that page is quite incredible. > > I'm also unsure where it mentions that virtualization is now obsolete. NFV > solutions are moving to VM based deployments as a stop-gap and for the > future, towards micro-services built in containers. > > On Fri, Jan 15, 2021 at 6:38 AM Etienne-Victor Depasquale > wrote: > >> Hello folks, >> >> Last year, I posted to this list and asked "has virtualization become >> obsolete in 5G"? >> >> A similar opinion seems to be gaining ground >> <https://www.telecomtvperspectives.com/series/vmware/the-countdown-to-5g-and-cloud-native/> >> .: >> >> "Once the darling of the telecoms industry, NFV has had a rough ride in >> recent years and has even lead some industry observers to proclaim that NFV >> is dead." >> >> Cheers, >> >> Etienne >> >> -- >> Ing. Etienne-Victor Depasquale >> Assistant Lecturer >> Department of Communications & Computer Engineering >> Faculty of Information & Communication Technology >> University of Malta >> Web. https://www.um.edu.mt/profile/etiennedepasquale >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Follow up to "has virtualization become obsolete in 5G"?
Hello folks, Last year, I posted to this list and asked "has virtualization become obsolete in 5G"? A similar opinion seems to be gaining ground <https://www.telecomtvperspectives.com/series/vmware/the-countdown-to-5g-and-cloud-native/> .: "Once the darling of the telecoms industry, NFV has had a rough ride in recent years and has even lead some industry observers to proclaim that NFV is dead." Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Wildfires: Clear fuel from hilltop and remote area communications towers
Don, your answer to Eric's valid point is open to broad interpretation - what is your point, exactly? On Sat, Sep 12, 2020 at 3:24 AM Don Gould wrote: > Eric they have the same issues in Australia. You might want to join > aunog, if you haven't already, I'm sure you'll find endorsement for these > issues. > > Fuel management is a problem. Finding the right balance between management > and ecological issues is political and complex with many vested interests > driving the narrative. > > D > > > > -- > Don Gould > 5 Cargill Place > Richmond > Christchurch, New Zealand > Mobile/Telegram: + 64 21 114 0699 > www.bowenvale.co.nz > > > Original message > From: Eric Kuhnke > Date: 12/09/20 10:14 am (GMT+12:00) > To: "nanog@nanog.org list" > Subject: Wildfires: Clear fuel from hilltop and remote area communications > towers > > Over the past week I think I've seen about 20 to 30 photos of burnt out > communications sites in Oregon and California. > > Due to the often remote and unstaffed nature of many of these sites, > there's a natural tendency for brush, shrubs, grass and small trees to grow > close to the tower compounds on many hilltop sites. > > Many of these sites also support emergency communications services. > > In the subject line I'm using "fuel" as defined by firefighters, not > literally meaning petroleum fuels, but anything flammable. > > In some places there are ecological or political concerns with maintaining > a cleared perimeter around telecom tower sites. This might be a time to > re-visit the logical purpose of some of these policies, if allowing fuel to > grow right up to the tower and telecom equipment shelters greatly increases > the likelihood of the whole thing going up in flames. > > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Bottlenecks and link upgrades
+1
You can't foresee everything, but no plan means foreseeing nothing, =
blindfold.
Cheers,
Etienne
On Sat, Aug 15, 2020 at 12:29 PM Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:
> On Sat, Aug 15, 2020, at 11:35, Baldur Norddahl wrote:
> > No plan survives contact with the enemy. Your careful made growth
> > projection was fine until the brass made a deal with some major
> > customer, which caused a traffic spike.
>
> Capacity planning also includes keeping an eye on what is being sold and
> what is being prepared.
> Having the traffic more than double within a 48h timespan (until day X
> peak at N Gbps, after days X+2, peaks at 2.5*N Gbps) -> done with success
> when the correct information ("partner X will change delivery system")
> arrived 4 months in advance.
>
> Having multiple 200 Mbps and 500 Mbps connections over an already-used 1
> Gbps port and pretending that "everything's gonna be allright" , in that
> case you should confront your enemy.
>
> > Or any infinite other events that could and eventually will happen to
> you.
>
> Among which you try to protect yourself against the most realistic ones.
>
> > One hard thing, that almost everyone will get wrong at some point, is
> > simulating load in the event multiple outages takes some links out,
> > causing excessive traffic to reroute unto links that previously seemed
> > fine.
>
> You should scale the network to absorb a certain degree of
> "surprise"/damage, and clearly explain that beyond that certain level,
> service will be degraded (or even absent) and there is nothing that can and
> nothing that will be done immediately.
>
> Every network fails at a certain moment in time. You just need to make
> sure you know how to make it working again, within a reasonable time frame.
> Or have a good run-away plan (sometimes this is the best solution).
>
--
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Bottlenecks and link upgrades
I've seen the weekly profiles of traffic sourced from caches for the major global services (video, social media, search and general) for a specific metro area. For all services, the weekly profile is a repetition of the daily profile, within +/- 20%. That is: the weekly profile is obtained from the daily profile within +/- 20% of the average daily profile height. Given this regularity, as suggested by Louie Lee, then it seems that growth projections are meaningful. That is, the weely profile data, seem to provide a sound empirical basis for link upgrades. Since I'm not an operator, my comments need to be sprinkled with a pinch of salt :) Cheers, Etienne On Sat, Aug 15, 2020 at 2:43 AM Louie Lee via NANOG wrote: > Beyond a pure percentage, you might want to account for the time it takes > you stay below a certain threshold. If you want to target a certain link to > keep your 95th percentile peaks below 70%, then first get an understanding > of your traffic growth and try to project when you will reach that number. > You have to decide whether you care about the occasional peak, or the > consistent peak, or somewhere in between, like weekday vs weekends, etc. > Now you know how much lead time you will have. > > Then consider how long it will take you to upgrade that link. If it's a > matter of adding a couple of crossconnects, then you might just need a > week. If you have to ship and install optics, modules, a card, then add > another week. If you have to get a sales order signed by senior management, > add another week. If you have to put it through legal and finance, add a > month. (kidding) If you are doing your annual re-negotiation, well...good > luck. > > It's always good to ask your circuit vendors what the lead times are, then > double it and add 5. > > And sometimes, if you need a low latency connection, traffic utilization > levels might not even be something you look at. > > Louie > Peering Coordinator at a start-up ISP > > > On Fri, Aug 14, 2020 at 4:13 PM Radu-Adrian Feurdean < > na...@radu-adrian.feurdean.net> wrote: > >> On Wed, Aug 12, 2020, at 09:31, Hank Nussbacher wrote: >> > At what point do commercial ISPs upgrade links in their backbone as >> > well as peering and transit links that are congested? At 80% capacity? >> > 90%? 95%? >> >> Some reflections about link capacity: >> At 90% and over, you should panic. >> Between 80% and 90% you should be (very) scared. >> Between 70% and 80% you should be worried. >> Between 60% and 70% you should seriously consider speeding up the >> upgrades that you effectively started at 50%, and started planning since >> 40%. >> >> Of course, that differs from one ISP to another. Some only upgrade after >> several months with at least 4 hours a day, every day (or almost) at over >> 95%. Others deploy 10x expected capacity, and upgrade well before 40%. >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Bottlenecks and link upgrades
> > There is rarely a one sized fits all answer when it comes to these > things. > Absolutely true: every application has characteristic QoS parameters. Unfortunately, it seems that 5-minute averages of data rates through links are the one-size-fits-all answer ... which doesn't fit all. Etienne On Thu, Aug 13, 2020 at 5:37 PM Tom Beecher wrote: > Wouldn't it be better to measure the basic performance like packet drop >> rates and queue sizes ? >> > > Those values should be a standard part of monitoring and data collection, > but if they happen to MATTER or not in a given situation very much depends. > > The traffic profile traversing the link may be such that the observed drop > % and buffer depths is acceptable for that traffic, and there is no need > for further tuning or changes. In other scenarios it may not be, in which > case either network or application adjustments are warranted. > > There is rarely a one sized fits all answer when it comes to these things. > > > On Thu, Aug 13, 2020 at 6:25 AM Olav Kvittem via NANOG > wrote: > >> >> On 12.08.2020 09:31, Hank Nussbacher wrote: >> >> At what point do commercial ISPs upgrade links in their backbone as well >> as peering and transit links that are congested? At 80% capacity? 90%? >> 95%? >> >> >> Hi, >> >> >> Wouldn't it be better to measure the basic performance like packet drop >> rates and queue sizes ? >> >> These days live video is needed and these parameters are essential to the >> quality. >> >> Queues are building up in milliseconds and people are averaging over >> minutes to estimate quality. >> >> >> If you are measuring queue delay with high frequent one-way-delay >> measurements >> >> you would then be able to advice better on what the consequences of a >> highly loaded link are. >> >> >> We are running a research project on end-to-end quality and the enclosed >> image is yesterdays report on >> >> queuesize(h_ddelay) in ms. It shows stats on delays between some peers. >> >> I would have looked at the trends on the involved links to see if upgrade >> is necessary - >> >> 421 ms might be too much ig it happens often. >> >> >> Best regards >> >> >> Olav Kvittem >> >> >> >> Thanks, >> Hank >> >> >> Caveat: The views expressed above are solely my own and do not express >> the views or opinions of my employer >> >> -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Bottlenecks and link upgrades
> > With tongue in cheek, one could say that measured instantaneously, the > load on a link is always either zero or 100% link rate... > Actually, that's a first-class observation ! On Thu, Aug 13, 2020 at 12:00 PM Simon Leinen wrote: > m Taichi writes: > > Just my curiosity. May I ask how we can measure the link capacity > > loading? What does it mean by a 50%, 70%, or 90% capacity loading? > > Load sampled and measured instantaneously, or averaging over a certain > > period of time (granularity)? > > Very good question! > > With tongue in cheek, one could say that measured instantaneously, the > load on a link is always either zero or 100% link rate... > > ISPs typically sample link load in 5-minute intervals and look at graphs > that show load (at this 5-minute sampling resolution) over ~24 hours, or > longer-term graphs where the resolution has been "downsampled", where > downsampling usually smoothes out short-term peaks. > > From my own experience, upgrade decisions are made by looking at those > graphs and checking whether peak traffic (possibly ignoring "spikes" :-) > crosses the threshold repeatedly. > > At some places this might be codified in terms of percentiles, e.g. "the > Nth percentile of the M-minute utilization samples exceeds X% of link > capacity over a Y-day period". I doubt that anyone uses such rules to > automatically issue upgrade orders, but maybe to generate alerts like > "please check this link, we might want to upgrade it". > > I'd be curious whether other operators have such alert rules, and what > N/M/X/Y they use - might well be different values for different kinds of > links. > -- > Simon. > PS. We use the "stare at graphs" method, but if we had automatic alerts, > I guess it would be something like "the 95th percentile of 5-minute > samples exceeds 50% over 30 days". > PPS. My colleagues remind me that we do alert on output queue drops. > > > These are questions have bothered me for long. Don't know if I can ask > > about these by the way. I take care of the radio access network > > performance at work. Found many things unknown in transport network. > > > Thanks and best regards, > > Taichi > > > On Wed, Aug 12, 2020 at 3:54 PM Mark Tinka > wrote: > > > On 12/Aug/20 09:31, Hank Nussbacher wrote: > > > At what point do commercial ISPs upgrade links in their backbone as > well as peering and transit links that are congested? At 80% > > capacity? 90%? 95%? > > > We start the process at 50% utilization, and work toward completing the > upgrade by 70% utilization. > > > The period between 50% - 70% is just internal paperwork. > > > Mark. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > Moreover, an employer doesn't have to give in to the whims of a > conceited employee; and most do not. > This point plays straight up the path of the argument I recounted. Yes, I agree that there's a relational problem inherent to the situation I described. Wouldn't any wise employer playing the relationship game ensure that he's got cards to play? And wouldn't the standardization approach be part of the deck? Cheers, Etienne On Wed, Aug 12, 2020 at 10:00 AM Mark Tinka wrote: > > > On 12/Aug/20 09:49, Etienne-Victor Depasquale wrote: > > > Two more bits' worth ... > > > > About a year ago, during a discussion with a local network operator's > CTO, > > I was told that dependency on the operator's employees > > for production of software gave the employees too much leverage over > > their employer (the operator, here). > > > > Perhaps industrial standardization of internal processes (including > > orchestration APIs) weakens this leverage. > > I'm not sure that's a viable argument considering that any good employee > (network, software, e.t.c.) will inherently have considerable leverage > over their employer. And any good employer knows what to do when they > realize they have good talent - either they do what is required to > maintain that talent, or live with the risk of losing that talent to the > competition. > > Moreover, an employer doesn't have to give in to the whims of a > conceited employee; and most do not. > > Standardizing processes would do little to allay the fears of a CTO who > is worried about being "cornered" by his/her staff. The real fear such a > CTO would have is in implementation and operation of those processes at > a technology level, i.e., where the rubber meets the actual road. > > If companies are going to be that scared by their employees, and if > employees are going to play games with their employers, they each have > other problems to solve, first :-). > > Mark. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
Two more bits' worth ... About a year ago, during a discussion with a local network operator's CTO, I was told that dependency on the operator's employees for production of software gave the employees too much leverage over their employer (the operator, here). Perhaps industrial standardization of internal processes (including orchestration APIs) weakens this leverage. Cheers, Etienne On Tue, Aug 11, 2020 at 8:48 PM Mark Tinka wrote: > > > On 11/Aug/20 17:55, adamv0...@netconsultings.com wrote: > > > Can you elaborate? > > Apart from licensing scheme what stops one from redirecting traffic to > one vTMS instance per say each transit link or per destination /24 (i.e. > horizontal scaling)? (vTMS is not stateful or is it?) > > In an effort to control costs, we considered a vTMS from Arbor. > > Even Arbor didn't recommend it, which was completely unsurprising. > > Arbor can flog you a TMS that can sweep 10Gbps, 20Gbps, 40Gbps or > 100Gbps worth of traffic. I don't see how you can run that kind of > traffic in a VM. > > > > > Can you please point out any efforts where operators are trying to > standardize the orchestration piece? > > NETCONF, YANG, LSO. > > > > I think industry is not falling over on this just progressing at steady > rate while producing artefacts in the process that you may or may not want > to use (I actually find them very useful and not impeding). > > What's 10 years between friends :-)... > > > > Personally, I don't need a standard on how I should orchestrate network > services. There are very interesting and useful ideas, or better put > "frameworks", that anyone can follow (and most are), but standardizing > these, ...no point in my opinion. > > Now that's something we can agree on... and once folk realize that > getting your solution going is the end-goal - rather than bickering over > whether NETCONF or YANG or SSH or whatever should be the BCOP - is when > we shall finally see some real progress. > > Personally, I don't really care of you choose to keep CLI or employ > thousands of software heads to automate said CLI. As long as you are > happy and not wasting time taking every meeting from every vendor about > "automation". > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > Well, I doubt the radio has any service intelligence. It's just a conduit. > Depending on why two devices on the same radio have to communicate, a > cleverer system deep in the core would need to process that before handing > it back to the radio network. > 5G introduced a number of functional units (RU, DU and CU) in the radio access network and disaggregation is flexible. Service intelligence doesn't need to come from the core; it may be far out in the edge. At the RU, there is packetized data ready for transmission over eCPRI to the DU. In this webinar <https://www.lightreading.com/webinar.asp?webinar_id=1656> (@6:07), there's a bit of a projection about use of service intelligence. Cheers, Etienne On Thu, Aug 6, 2020 at 10:21 AM Mark Tinka wrote: > > > On 5/Aug/20 18:34, Etienne-Victor Depasquale wrote: > > > Release 16 is just out and if it has delivered the 5G vision, > latency between devices connected over the same radio interface > (which I take to mean the same gNB), > is now < 1 ms. > Isn't that a good improvement? > > > Well, I doubt the radio has any service intelligence. It's just a conduit. > Depending on why two devices on the same radio have to communicate, a > cleverer system deep in the core would need to process that before handing > it back to the radio network. > > Of course, it makes the case for deploying services at each base station > to localize services, but that could get expensive for an entire radio > network, particularly within a 100km Metro where fibre latency will remain > at ±1ms anyway. > > Not to mention that with the exception of things like cars in a traffic > jam or on the same piece of highway, the chances of two devices talking to > each other over the same radio can't always be guaranteed. > > > > I understand that this is a key enabler for driverless cars (real-time, > automated vehicle navigation) - the V2I part of V2X. > > > I look forward to seeing this. > > > > Here's one blogger who agrees with you > <https://www.brighttalk.com/webcast/16515/349885?utm_source=brighttalk-recommend&utm_campaign=network_weekly_email&utm_medium=email&utm_content=company&utm_term=312020> > (@19:46) about coverage - and count me in. > But, I guess, it's fair to say that this is the chicken-and-egg conundrum > :) > > > The video won't play. Could be my browser. > > Anyway, time will tell. I see 5G roll-out density like rolling out fibre > in places only where the postal service can get to. But I hope I'm wrong. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > What I meant that as we've been deploying NFV as a VM, cloud-native means we take that VM and containerize it further. Umm, I don't think so. At least that's not the impression I got from the CNCF, Intel and Red Hat. They seem to be striving for K8s without the use of VM hypervisors. Etienne On Wed, Aug 5, 2020 at 2:12 PM Mark Tinka wrote: > > > On 4/Aug/20 17:45, adamv0...@netconsultings.com wrote: > > Not sure what you mean NFV is NFV, > > From NFV perspective cRDP is no different than vMX -it’s just a > virtualized router function nothing special… > > > What I meant that as we've been deploying NFV as a VM, cloud-native means > we take that VM and containerize it further. It's a further diffusion of > NFV, in my book. The benefits about the added de-layering (if one can call > it that) are left as an exercise to the operator. > > > > > Also with regards to NFV markets, it’s just CPE or telco-cloud (routing on > host, FWs, LBs and other domain specific network devices like SBCs), and > then RRs, no one sane would be replacing high throughput aggregation points > like PEs or core nodes with NFV ,unless one wants to get into some serious > horizontal scaling ;). > > > Well, vCPE's and vBNG's have long been the holy grail for some of us, > especially since it makes IPv6 roll-out significantly simpler. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > And while the practical improvement in radio latency between 4G and 5G is in the low single digits, how does that make V2X any more interesting with 5G than it currently is with 4G? Release 16 is just out and if it has delivered the 5G vision, latency between devices connected over the same radio interface (which I take to mean the same gNB), is now < 1 ms. Isn't that a good improvement? Again, what's the actual use-case? > I understand that this is a key enabler for driverless cars (real-time, automated vehicle navigation) - the V2I part of V2X. 5G coverage is likely going to be worse than 4G coverage for the > foreseeable future. Either grid-locked or on the open road, chances are > your car is going to connecting to a 3G/4G cell tower more often than a > 5G one. > Here's one blogger who agrees with you <https://www.brighttalk.com/webcast/16515/349885?utm_source=brighttalk-recommend&utm_campaign=network_weekly_email&utm_medium=email&utm_content=company&utm_term=312020> (@19:46) about coverage - and count me in. But, I guess, it's fair to say that this is the chicken-and-egg conundrum :) Cheers, Etienne On Wed, Aug 5, 2020 at 1:36 PM Mark Tinka wrote: > > > On 4/Aug/20 17:37, Etienne-Victor Depasquale wrote: > > > > V2X, no? > > Again, what's the actual use-case? > > I've got a 4G router in my car, to which it connects via wi-fi. I can > use Google Maps, I can stream music if I'm bored with commercial radio, > I can download updates for the car and I can schedule service > appointments with the dealership. > > 5G coverage is likely going to be worse than 4G coverage for the > foreseeable future. Either grid-locked or on the open road, chances are > your car is going to connecting to a 3G/4G cell tower more often than a > 5G one. > > And while the practical improvement in radio latency between 4G and 5G > is in the low single digits, how does that make V2X any more interesting > with 5G than it currently is with 4G? > > Mark. > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
Intel definitely is pressing for containerized data plane. Here <https://intelvs.on24.com/vshow/inteldcgevents/#content/2393080>, @20:49 (registration required), I placed that very question and it took a bit of humming to obtain a straight answer :) Etienne On Tue, Aug 4, 2020 at 5:38 PM wrote: > Wondering whether the industry will consider containerised data-plane in > addition to control-plane (like cRDP). > > Having just control-plane and then hacking to kernel for doing the > data-plane bit is …well not as straight forward as having a dedicated > data-plane VM or potentially container. > > > > adam > > > > *From:* NANOG *On > Behalf Of *Etienne-Victor Depasquale > *Sent:* Saturday, August 1, 2020 7:09 PM > *To:* Robert Raszuk > *Cc:* NANOG > *Subject:* Re: Has virtualization become obsolete in 5G? > > > > Clearly to virtualize operating systems as long as your level of > virtualization mainly in terms of security and resource consumption > isolation & reservation is satisfactory is a much better and lighter > option. > > > > That pretty much sums up Intel's view. > > > > To quote an Intel executive I was corresponding with: > > > > "The purpose of the paper was to showcase how Communication Service > Providers can move to a more nimble and future proof microservices based > network architecture with cloud native functions, via container deployment > methodologies versus virtual machines. The paper cites many benefits of > moving to a microservices architecture beyond whether it is done in a VM > environment or cloud native. We believe the 5G networks of the future will > benefit greatly by implementing such an approach to deploying new services." > > > > The paper referred to is this one > <https://www.intel.in/content/www/in/en/communications/why-containers-and-cloud-native-functions-paper.html%20> > . > > > > Cheers, > > > > Etienne > > > > On Sat, Aug 1, 2020 at 6:23 PM Robert Raszuk wrote: > > I reason that Intel's implication is that virtualization is becoming > obsolete. > > Would anyone care to let me know his thoughts on this prediction? > > > > Virtualization is not becoming obsolete ... quite reverse in fact in all > types of deployments I can see around. > > > > The point is that VM provides hardware virtualization while kubernetes > with containers virtualize OS apps and services are running on in > isolation. > > > > Clearly to virtualize operating systems as long as your level of > virtualization mainly in terms of security and resource consumption > isolation & reservation is satisfactory is a much better and lighter > option. > > > > Thx, > > R. > > > > > > > -- > > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > PS. All of the current attempts to turn IP statistical multiplexing into > network slicing or deterministic networks are far from scale or practical > deployments (IMO). > Wow, that's quite a statement (I'm not disparaging, just surprised). Etienne On Tue, Aug 4, 2020 at 5:37 PM Robert Raszuk wrote: > > > I doubt we want to move away from those concepts. > > I think we all do - except technology is not there yet. Just imagine if > over a single piece of fiber you will get infinite bandwidth delivered over > unlimited modulation frequency spectrum ... > > IMHO till real true optical switching is a commodity we are stuck with > statistical multiplexing. > > But optimistically I think time will come when you will be able to > setup end to end optical paths in true any to any fashion with real end to > end resource guarantees. Then next generations will be looking at current > routers like we look today at strowger telephone switches :) > > Cheers, > R. > > PS. All of the current attempts to turn IP statistical multiplexing into > network slicing or deterministic networks are far from scale or practical > deployments (IMO). > > > > On Tue, Aug 4, 2020 at 5:18 PM Mark Tinka wrote: > >> >> >> On 4/Aug/20 16:56, Etienne-Victor Depasquale wrote: >> >> > The survey I pointed to suggests that hard slicing is the least >> > preferred option among survey respondents. >> >> That's because the very nature of DWDM, Ethernet, IP, MPLS and VM's is >> all about re-using the same infrastructure over and over again for it to >> make commercial sense. >> >> I doubt we want to move away from those concepts. >> >> We rely on many services today delivered over the public Internet that >> virtualize and still perform. Even good ol' video streaming, which was >> predicted to break the Internet. >> >> So not sure what applications are driving the demand for "greater QoS" >> on 5G networks, in real terms. >> >> Mark. >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > So not sure what applications are driving the demand for "greater QoS" > on 5G networks, in real terms. > Mark, V2X, no? Otherwise, I'm perfectly in agreement with what you've just written. Etienne On Tue, Aug 4, 2020 at 5:02 PM Mark Tinka wrote: > > > On 4/Aug/20 16:56, Etienne-Victor Depasquale wrote: > > > The survey I pointed to suggests that hard slicing is the least > > preferred option among survey respondents. > > That's because the very nature of DWDM, Ethernet, IP, MPLS and VM's is > all about re-using the same infrastructure over and over again for it to > make commercial sense. > > I doubt we want to move away from those concepts. > > We rely on many services today delivered over the public Internet that > virtualize and still perform. Even good ol' video streaming, which was > predicted to break the Internet. > > So not sure what applications are driving the demand for "greater QoS" > on 5G networks, in real terms. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
The survey I pointed to suggests that hard slicing is the least preferred option among survey respondents. Etienne On Tue, Aug 4, 2020 at 4:53 PM Mark Tinka wrote: > > > On 4/Aug/20 16:46, Djamel Sadok wrote: > > > > > > How about hardware slicing support? such as switch, server and router > > slicing? is this supported/desirable? > > So you mean dump the VLAN model and give each service its own switch? > > Or do you mean use one server but give each service its own VM? Or > worse, give each service its own metal server? > > Wouldn't that take us back into the digital stone age :-)? > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
I think that it's validation of QoS that really matters now. If I were to base on this recent video from Keysight <https://www.keysight.com/zz/en/events/america/webinars.html?D2C=2036435&isSocialSharing=Y&partnerref=emailShareFromGateway> (warning: requires registration), then it seems that there's a lot of emphasis on making grounded claims about the QoS that the operator sells. Cheers, Etienne On Mon, Aug 3, 2020 at 12:52 PM Mark Tinka wrote: > > > On 3/Aug/20 08:40, Etienne-Victor Depasquale wrote: > > Is the following extract from this Heavy Reading white paper > <https://www.infinera.com/wp-content/uploads/HR-Operator-Strategies-for-5G-Transport-July-2020_WP.pdf>, > useful? > > " For transport network slicing, > operators strongly prefer soft slicing with virtual private networks > (VPNs), > regardless of the VPN flavor. > Ranking at the top of the list was Layer 3 VPNs (selected by 66% of > respondents), > but Layer 2 VPNs, Ethernet VPNs (EVPNs), and segment routing > also ranked highly at 47%, 46%, and 46%, respectively. > The point is underscored by the low preferences among all of the hard > slicing technologies— > those that physically partition resources among slices. > Hard slicing options formed the bottom tier among preferences." > > > Well, it's what I've been saying - we have tried & tested systems and > solutions that are already native to IP/MPLS networks. Why try to reinvent > network virtualization when there are plenty of existing solutions in the > wild for next to cheap? VLAN's. l2vpn's. l3vpn's. EVPN. DWDM. And all the > rest? > > The whole fuss, for example, about the GRX vs. IPX all came down to 2Mbps > private or public IP-based GTP tunnels vs. 100Mbps l3vpn's. > > Mobile operators know how to make everyday protocols seem overly > complicated. > > If we go by their nomenclature, the simple operators on this list have > been slicing infrastructure for yonks :-). > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > Still not sure how this will work considering a great deal of the global > Internet is for services that live on the public Internet, and many > specialized/private services would typically still run over fibre. > Is the following extract from this Heavy Reading white paper <https://www.infinera.com/wp-content/uploads/HR-Operator-Strategies-for-5G-Transport-July-2020_WP.pdf>, useful? " For transport network slicing, operators strongly prefer soft slicing with virtual private networks (VPNs), regardless of the VPN flavor. Ranking at the top of the list was Layer 3 VPNs (selected by 66% of respondents), but Layer 2 VPNs, Ethernet VPNs (EVPNs), and segment routing also ranked highly at 47%, 46%, and 46%, respectively. The point is underscored by the low preferences among all of the hard slicing technologies— those that physically partition resources among slices. Hard slicing options formed the bottom tier among preferences." Etienne On Mon, Aug 3, 2020 at 7:42 AM Mark Tinka wrote: > > > On 2/Aug/20 06:51, Ahmed elBorno wrote: > > Maybe I am off topic a little bit here and i'd like to be educated if > > i am wrong but I think those 5G applications will move from VMs into > > containers/microservices when their vendors see a business case to > > rearchitect them, maybe its already happening as we speak. > > I'm still trying to figure out what "these 5G applications" are :-). > > > > > > On the other side of that coin is that product managers of these 5G > > apps seeing the margins on their apps diminish when they slice them to > > a form that allows other "orchestrators" to deploy them. > > My understanding of "network slicing" is that an operator lets an MVNO > ride their network (happens today already), and that MVNO can further > "slice" their portion of the operators network to deliver different > performance levels for the different services they offer down to the > end-user. > > Still not sure how this will work considering a great deal of the global > Internet is for services that live on the public Internet, and many > specialized/private services would typically still run over fibre. I > know we'd all like to see heart surgery over 5G, but something tells me > if you can afford it, the hospital can afford some fibre :-). > > Perhaps M2M may have a use-case, but that's working reasonably well on > 4G today, unless we expect to see a massive jump in performance with the > marginal improvement in radio latency between device and 5G tower. > > > > > > Another side is that the software engineers working on these Apps have > > a lot more prioritized items/things to develop (real core functions) > > so they will delay this transformation. > > This is the crux of the issue. > > Mark. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
I'm sorry, I didn't realize that anyone would get ruffled. On Sat, Aug 1, 2020 at 11:38 PM Scott Weeks wrote: > > > --- ed...@ieee.org wrote: > From: Etienne-Victor Depasquale > > See, for example, Azhar Sayeed's (Red Hat) contribution here > <https://www.lightreading.com/webinar.asp?webinar_id=1608>@15:33. > > > > Don't send links to this list that require one to register > to read the article and then say, "By registering for our > site, your email will be added to our promotions list" and > "Occasionally our trusted partners may want to send you > information about exciting new products and services" > > No one's going to click on that! > > scott > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > Clearly to virtualize operating systems as long as your level of > virtualization mainly in terms of security and resource consumption > isolation & reservation is satisfactory is a much better and lighter > option. > That pretty much sums up Intel's view. To quote an Intel executive I was corresponding with: "The purpose of the paper was to showcase how Communication Service Providers can move to a more nimble and future proof microservices based network architecture with cloud native functions, via container deployment methodologies versus virtual machines. The paper cites many benefits of moving to a microservices architecture beyond whether it is done in a VM environment or cloud native. We believe the 5G networks of the future will benefit greatly by implementing such an approach to deploying new services." The paper referred to is this one <https://www.intel.in/content/www/in/en/communications/why-containers-and-cloud-native-functions-paper.html> . Cheers, Etienne On Sat, Aug 1, 2020 at 6:23 PM Robert Raszuk wrote: > I reason that Intel's implication is that virtualization is becoming >> obsolete. >> Would anyone care to let me know his thoughts on this prediction? >> > > Virtualization is not becoming obsolete ... quite reverse in fact in all > types of deployments I can see around. > > The point is that VM provides hardware virtualization while kubernetes > with containers virtualize OS apps and services are running on in > isolation. > > Clearly to virtualize operating systems as long as your level of > virtualization mainly in terms of security and resource consumption > isolation & reservation is satisfactory is a much better and lighter > option. > > Thx, > R. > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Has virtualization become obsolete in 5G?
> > Be careful not to confuse vendors pumping stuff with whats actually > deployed. > Well yes, there's always the hype factor to discount. The reason why I'm asking this forum is to separate hype from hope. Also, AT&T has been doing virtualization for nearly 10 years now, so > perhaps you were just not paying attention But the point is just that: how serious is this progression towards cloud-native, if so much effort was put in to virtualization? Incidentally, AT&T's Brian Bearden was present here <https://intelvs.on24.com/vshow/inteldcgevents/#content/2393080>: just listen to how he defended Intel's containerization drive @24:56. > > On Sat, Aug 1, 2020 at 4:33 PM Ca By wrote: > > > On Sat, Aug 1, 2020 at 7:21 AM Etienne-Victor Depasquale > wrote: > >> The surprise for me regards Intel's (and the entire Cloud Native >> Computing Foundation's?) readiness to move past network functions run on >> VMs >> and towards network functions run as microservices in containers. >> >> See, for example, Azhar Sayeed's (Red Hat) contribution here >> <https://www.lightreading.com/webinar.asp?webinar_id=1608>@15:33. >> > > Be careful not to confuse vendors pumping stuff with whats actually > deployed. > > Also, AT&T has been doing virtualization for nearly 10 years now, so > perhaps you were just not paying attention > > > https://www.fiercetelecom.com/telecom/at-t-target-for-virtualizing-75-its-network-by-2020 > > Not sure it has helped ATT in any meaningful way, their stock price is > the same it was in 2015. > > >> Cheers, >> >> Etienne >> >> On Sat, Aug 1, 2020 at 2:35 PM Mark Tinka wrote: >> >>> >>> >>> On 1/Aug/20 11:23, Etienne-Victor Depasquale wrote: >>> >>> Over the past few weeks, I've attended webinars and watched videos >>> organized by Intel. >>> These activities have centred on 5G and examined applications (like >>> "visual cloud" and "gaming"), >>> as well as segment-oriented aspects (like edge networks, 5G RAN and 5G >>> Core). >>> >>> I am stunned (no hyperbole) by the emphasis on Kubernetes in particular, >>> and cloud-native computing in general. >>> Equally stunning (for me), public telecommunications networks have been >>> portrayed >>> as having a history that moved from integrated software and hardware, >>> to virtualization and now to cloud-native computing. >>> See, for example Alex Quach, here >>> <https://www.telecomtv.com/content/intel-vsummit-5g-ran-5g-core/the-5g-core-is-vital-to-deliver-the-promise-of-5g-39164/> >>> @10:30). >>> I reason that Intel's implication is that virtualization is becoming >>> obsolete. >>> >>> Would anyone care to let me know his thoughts on this prediction? >>> >>> >>> In the early dawn of SDN, where it was cool to have the RP's in Beirut >>> and the line cards in Lagos, the industry quickly realized that was not >>> entirely feasible. >>> >>> If you are looking at over-the-top services, so-called cloud-native >>> computing makes sense in order to deliver that value accordingly, and with >>> agility. But as it pertains to actual network transport, I'm not yet sure >>> the industry is at the stage where we are confident enough to decompose >>> packet forwarding through a cloud. >>> >>> Network operators are more likely to keep using kit that integrates >>> forwarding hardware as well as a NOS, as no amount of cloud architecting is >>> going to rival a 100Gbps purpose-built port, for example. >>> >>> Suffice it to say, there was a time when folk were considering running >>> their critical infrastructure (such as your route reflectors) in AWS or >>> similar. I'm not quite sure public clouds are at that level of confidence >>> yet. So if some kind of cloud-native infrastructure is to be considered for >>> critical infrastructure, I highly suspect it will be in-house. >>> >>> On the other hand, for any new budding entrepreneurs that want to get >>> into the mobile game with as little cost as possible, there is a huge >>> opportunity to do so by building all that infrastructure in an on-prem >>> cloud-native architecture, and offer packet forwarding using >>> general-purpose hardware provided they don't exceed their expectations. >>> This way, they wouldn't have to deal with the high costs traditional >>> vendors
Re: Has virtualization become obsolete in 5G?
The surprise for me regards Intel's (and the entire Cloud Native Computing Foundation's?) readiness to move past network functions run on VMs and towards network functions run as microservices in containers. See, for example, Azhar Sayeed's (Red Hat) contribution here <https://www.lightreading.com/webinar.asp?webinar_id=1608>@15:33. Cheers, Etienne On Sat, Aug 1, 2020 at 2:35 PM Mark Tinka wrote: > > > On 1/Aug/20 11:23, Etienne-Victor Depasquale wrote: > > Over the past few weeks, I've attended webinars and watched videos > organized by Intel. > These activities have centred on 5G and examined applications (like > "visual cloud" and "gaming"), > as well as segment-oriented aspects (like edge networks, 5G RAN and 5G > Core). > > I am stunned (no hyperbole) by the emphasis on Kubernetes in particular, > and cloud-native computing in general. > Equally stunning (for me), public telecommunications networks have been > portrayed > as having a history that moved from integrated software and hardware, > to virtualization and now to cloud-native computing. > See, for example Alex Quach, here > <https://www.telecomtv.com/content/intel-vsummit-5g-ran-5g-core/the-5g-core-is-vital-to-deliver-the-promise-of-5g-39164/> > @10:30). > I reason that Intel's implication is that virtualization is becoming > obsolete. > > Would anyone care to let me know his thoughts on this prediction? > > > In the early dawn of SDN, where it was cool to have the RP's in Beirut and > the line cards in Lagos, the industry quickly realized that was not > entirely feasible. > > If you are looking at over-the-top services, so-called cloud-native > computing makes sense in order to deliver that value accordingly, and with > agility. But as it pertains to actual network transport, I'm not yet sure > the industry is at the stage where we are confident enough to decompose > packet forwarding through a cloud. > > Network operators are more likely to keep using kit that integrates > forwarding hardware as well as a NOS, as no amount of cloud architecting is > going to rival a 100Gbps purpose-built port, for example. > > Suffice it to say, there was a time when folk were considering running > their critical infrastructure (such as your route reflectors) in AWS or > similar. I'm not quite sure public clouds are at that level of confidence > yet. So if some kind of cloud-native infrastructure is to be considered for > critical infrastructure, I highly suspect it will be in-house. > > On the other hand, for any new budding entrepreneurs that want to get into > the mobile game with as little cost as possible, there is a huge > opportunity to do so by building all that infrastructure in an on-prem > cloud-native architecture, and offer packet forwarding using > general-purpose hardware provided they don't exceed their expectations. > This way, they wouldn't have to deal with the high costs traditional > vendors (Ericsson, Nokia, Huawei, Siemens, ZTE, e.t.c.) impose. Granted, it > would be small scale, but maybe that is the business model. And in an > industry where capex is fast out-pacing revenue, it would be the mobile > network equivalent of low-cost carrier airlines. > > I very well could be talking out the side of my neck, but my prediction is > mobile operators will be optimistic but cautious. I reckon a healthy mix > between cloud-native and tried & tested practices. > > Mark. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Has virtualization become obsolete in 5G?
Hi folks, Over the past few weeks, I've attended webinars and watched videos organized by Intel. These activities have centred on 5G and examined applications (like "visual cloud" and "gaming"), as well as segment-oriented aspects (like edge networks, 5G RAN and 5G Core). I am stunned (no hyperbole) by the emphasis on Kubernetes in particular, and cloud-native computing in general. Equally stunning (for me), public telecommunications networks have been portrayed as having a history that moved from integrated software and hardware, to virtualization and now to cloud-native computing. See, for example Alex Quach, here <https://www.telecomtv.com/content/intel-vsummit-5g-ran-5g-core/the-5g-core-is-vital-to-deliver-the-promise-of-5g-39164/> @10:30). I reason that Intel's implication is that virtualization is becoming obsolete. Would anyone care to let me know his thoughts on this prediction? Cheers all, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasqualeI
Re: understanding IPv6
The proposal seems to be aimed at more than that. One major problem which this proposal addresses is assignment of IPv6 subnets to links as transient and unreliable as links between IoT nodes. My ***guess*** is that binding an IPv6 subnet to a link that elusive would be bad for routing. Etienne On Sun, Jun 7, 2020 at 9:33 PM Baldur Norddahl wrote: > What I do not understand about this proposal is why we do not just fix > wireless multicast? For example the AP could unicast multicast frames to > subscribed STA and combined with MLD snooping we are done. Would be > backwards compatible too, compared to a whole new protocol which will take > decades to gain traction. > > Regards, > > Baldur > > > On Sun, Jun 7, 2020 at 8:59 PM Joel Halpern wrote: > >> Just to clarify context, at this stage this is just Pascal's interesting >> idea for how to make ND work better on wireless. No IETF working group >> has adopted this. Various people seem to be interested, but it will be >> some time before we know if his approach gets traction. >> >> The biggest difference between this and earlier changes along this line >> is that the wireless broadcast problem provides motivation for the >> change, where earlier efforts were more ~wouldn't it just be simpler >> if...~ >> >> Yours, >> Joel Halpern >> >> On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote: >> > What I'm amazed at is the concept of multi-link subnet and the change >> in >> > IP model being proposed. >> > >> > See, for example, section 4 of >> > https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05 >> > >> > Has anyone felt the same about the change being proposed? This swept >> > away 25 years of thinking about IP subnets and IP links for me. >> > >> > Etienne >> > >> > On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin > > <mailto:lists.na...@monmotha.net>> wrote: >> > >> > On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote: >> > > There are very interesting and unobvious moments on IPv4 vs IPv6, >> > for >> > > example related to battery lifetime in embedded electronics. In >> > ipv4, >> > > many devices are forced to send "keepalives" so that the NAT >> > entry does >> > > not disappear, with IPv6 it is not required and bidirectional >> > > communications possible at any time. And in fact, it has a huge >> > impact >> > > on the cost and battery life of IoT devices. >> > > When I developed some IoT devices for clients, it turned out >> that if >> > > "IPv6-only" is possible, this significantly reduces the cost of >> the >> > > solution and simplify setup. >> > >> > This is difficult to understate. "People" are continually amazed >> > when I >> > show them that I can leave TCP sessions up for days at a time (with >> > properly configured endpoints) with absolutely zero keepalive >> traffic >> > being exchanged. >> > >> > As amusingly useful as this may be, it pales in comparison to the >> > ability to do the same on deeply embedded devices running off small >> > primary cell batteries. I've got an industrial sensor network >> product >> > where the device poll interval is upwards of 10 minutes, and even >> then >> > it only turns on its receiver. The transmitter only gets lit up >> about >> > once a day for a "yes I'm still here" notification unless it has >> > something else to say. >> > >> > In the end, we made it work across IPv4 by inserting an application >> > level gateway. We just couldn't get reliable, transparent IPv6 >> > full-prefix connectivity from any of the cellular telematics >> providers >> > at the time. I don't know if this has changed. For our >> application, >> > this was fine, but for mixed vendor "IoT" devices, it would probably >> > not >> > work out well. >> > -- >> > Brandon Martin >> > >> > >> > >> > -- >> > Ing. Etienne-Victor Depasquale >> > Assistant Lecturer >> > Department of Communications & Computer Engineering >> > Faculty of Information & Communication Technology >> > University of Malta >> > Web. https://www.um.edu.mt/profile/etiennedepasquale >> >> -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: understanding IPv6
" Multi links subnets are not a figment of my mind. ". Precisely. Two years ago, while lecturing a related study-unit for the first time, I encountered this document: http://www.ti.com/lit/pdf/swry013 and it was by then already 4 years old. Figure 1 is inexplicable without the concept of the multi-link subnet. Cheers, Etienne On Sun, Jun 7, 2020 at 9:05 PM Pascal Thubert (pthubert) wrote: > Hello Joel: > > The draft is supposed to be factual not divagations; if I went too far > somewhere I need to fix the draft. As you said it is early personal > submission. > > Multi links subnets are not a figment of my mind. We have millions of > routers deployed that way, using RPL as the subnet routing protocol. > Admittedly this is IoT but this is true nevertheless. > > Keep safe, > > Pascal > > > Le 7 juin 2020 à 21:00, Joel Halpern a écrit : > > > > Just to clarify context, at this stage this is just Pascal's > interesting idea for how to make ND work better on wireless. No IETF > working group has adopted this. Various people seem to be interested, but > it will be some time before we know if his approach gets traction. > > > > The biggest difference between this and earlier changes along this line > is that the wireless broadcast problem provides motivation for the change, > where earlier efforts were more ~wouldn't it just be simpler if...~ > > > > Yours, > > Joel Halpern > > > >> On 6/7/2020 2:28 PM, Etienne-Victor Depasquale wrote: > >> What I'm amazed at is the concept of multi-link subnet and the change > in IP model being proposed. > >> See, for example, section 4 of > https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05 > >> Has anyone felt the same about the change being proposed? This swept > away 25 years of thinking about IP subnets and IP links for me. > >> Etienne > >> On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin <mailto:lists.na...@monmotha.net>> wrote: > >>On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote: > >> > There are very interesting and unobvious moments on IPv4 vs IPv6, > >>for > >> > example related to battery lifetime in embedded electronics. In > >>ipv4, > >> > many devices are forced to send "keepalives" so that the NAT > >>entry does > >> > not disappear, with IPv6 it is not required and bidirectional > >> > communications possible at any time. And in fact, it has a huge > >>impact > >> > on the cost and battery life of IoT devices. > >> > When I developed some IoT devices for clients, it turned out that > if > >> > "IPv6-only" is possible, this significantly reduces the cost of > the > >> > solution and simplify setup. > >>This is difficult to understate. "People" are continually amazed > >>when I > >>show them that I can leave TCP sessions up for days at a time (with > >>properly configured endpoints) with absolutely zero keepalive traffic > >>being exchanged. > >>As amusingly useful as this may be, it pales in comparison to the > >>ability to do the same on deeply embedded devices running off small > >>primary cell batteries. I've got an industrial sensor network > product > >>where the device poll interval is upwards of 10 minutes, and even > then > >>it only turns on its receiver. The transmitter only gets lit up > about > >>once a day for a "yes I'm still here" notification unless it has > >>something else to say. > >>In the end, we made it work across IPv4 by inserting an application > >>level gateway. We just couldn't get reliable, transparent IPv6 > >>full-prefix connectivity from any of the cellular telematics > providers > >>at the time. I don't know if this has changed. For our application, > >>this was fine, but for mixed vendor "IoT" devices, it would probably > >>not > >>work out well. > >>-- Brandon Martin > >> -- > >> Ing. Etienne-Victor Depasquale > >> Assistant Lecturer > >> Department of Communications & Computer Engineering > >> Faculty of Information & Communication Technology > >> University of Malta > >> Web. https://www.um.edu.mt/profile/etiennedepasquale > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: understanding IPv6
What I'm amazed at is the concept of multi-link subnet and the change in IP model being proposed. See, for example, section 4 of https://tools.ietf.org/html/draft-thubert-6man-ipv6-over-wireless-05 Has anyone felt the same about the change being proposed? This swept away 25 years of thinking about IP subnets and IP links for me. Etienne On Sun, Jun 7, 2020 at 6:03 PM Brandon Martin wrote: > On 6/7/20 6:01 AM, Denys Fedoryshchenko wrote: > > There are very interesting and unobvious moments on IPv4 vs IPv6, for > > example related to battery lifetime in embedded electronics. In ipv4, > > many devices are forced to send "keepalives" so that the NAT entry does > > not disappear, with IPv6 it is not required and bidirectional > > communications possible at any time. And in fact, it has a huge impact > > on the cost and battery life of IoT devices. > > When I developed some IoT devices for clients, it turned out that if > > "IPv6-only" is possible, this significantly reduces the cost of the > > solution and simplify setup. > > This is difficult to understate. "People" are continually amazed when I > show them that I can leave TCP sessions up for days at a time (with > properly configured endpoints) with absolutely zero keepalive traffic > being exchanged. > > As amusingly useful as this may be, it pales in comparison to the > ability to do the same on deeply embedded devices running off small > primary cell batteries. I've got an industrial sensor network product > where the device poll interval is upwards of 10 minutes, and even then > it only turns on its receiver. The transmitter only gets lit up about > once a day for a "yes I'm still here" notification unless it has > something else to say. > > In the end, we made it work across IPv4 by inserting an application > level gateway. We just couldn't get reliable, transparent IPv6 > full-prefix connectivity from any of the cellular telematics providers > at the time. I don't know if this has changed. For our application, > this was fine, but for mixed vendor "IoT" devices, it would probably not > work out well. > -- > Brandon Martin > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Etienne Victor > > Maybe you’re confusing link and a subnet? > > This is discussed at length here: > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ > > RPL can route inside a subnet using host routes. This is how a multi link > subnet can be made to work... > > Please let me know if the draft above helped and whether it is clear > enough. The best way for that discussion would be to cc 6MAN. > > Keep safe, > > Pascal > > Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale a > écrit : > > > Thank you Carsten, and thank you Pacal. Your replies are valuable and > packed with insight. > > I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. > > On one hand, RFC6775 defines a route-over topology as follows: > "A topology where hosts are connected to the 6LBR through the use of > intermediate layer-3 (IP) routing. > Here, hosts are typically multiple IP hops away from a 6LBR. > The route-over topology typically consists of a 6LBR, a set of 6LRs, and > hosts." > If RPL is route-over by definition, then RFC6775 would imply that there > are typically multiple IP hops between a leaf and the border router. > > On the other hand, there at least two contradictions (which I justify > after stating them): > (a) RFC6550 states that "RPL also introduces the capability to bind a > subnet together with a common prefix and to route within that subnet." > (b) Reduction of a DODAG to a single subnet prefix, albeit only only one > parent-child relationship deep, is clearly shown at Contiki-NG's Github > page (deep dive section). > > The hinge on which my understanding revolves is that an IP hop traverses a > router and ***results in a change of prefix of the link on which the packet > travels*** : > > --> > --> > > With RPL, the "hop" would look like as shown below: > > -- > -- > > There seems to be a change in the meaning associated with "IP hop". > I guess that I can reconcile both cases through the observation that RPL > actually does apply to a single, NBMA link and therefore the IP prefix > ***is*** the same. > Then again, calling the RPL device involved in the packet forwarding by > the name "router" feels like an uncomfortable stretch. > Don't routers sit at the meeting point of different layer 2 links? > > > Cheers, > > Etienne > > On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) < > pthub...@cisco.com> wrote: > >> Hello Etienne >> >> You may see ND as the host to * interface for any network and RPL as the >> router to router interface when the network is NBMA. >> >> Some of us cared about the interworking. >> >> Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. >> >> Keep safe, >> >> Pascal >> >> > Le 29 mai 2020 à 20:28, Carsten Bormann a écrit : >> > >> > Hi Etienne, >> > >> > I’m also not sure many of the classical network operators assembled in >> NANOG work with 6LoWPANs today, but I still can answer your question. >> > >> >> While trying to build a holistic view of LoWPANs, I'm consulting the >> IETF's informational and standards documents. >> >> >> >> I'm struck by the impression that, despite the significance of >> RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy >> networks (LLNs), >> >> it is largely ignored by RFC6550 (RPL), with little to no reference to >> the ontological plane created in RFC6775's terminology section. >> > >> > Yes,
Re: Contact at Ubiquiti Networks?
I disagree with your certainty, Saku. That's best left to results in papers, as you correctly point out. On Wed, May 27, 2020 at 9:07 AM Saku Ytti wrote: > > > On Wed, 27 May 2020 at 10:00, Mel Beckman wrote: > > Hertz car rental has the #1 product in its industry, even its major >> competitor Avis agrees (“We’re number two“:-), and yet Hertz stock is >> plunging towards zero even as we speak. Stock price has nothing to do with >> product quality. Theranos, for example, had a completely fictional product, >> yet it stock price skyrocketed. >> > > I agree with the sentiment that stock value cannot be used to glean > ~anything, certainly not something specific like 'marketability of > product'. I'd be interested in reading paper where stock value is > determined to be more reliable than random metric on anything except stock > value. > > However Hertz depreciation is caused by the anticipation that debtors will > receive almost all of the equity, diluting the current owners by massive > ratio. The value tries to reflect post-dilution value. My Stetson-Harrision > analysis tells that current owners will end up owning less than 20% of > Hertz and more than 80% goes to debtors. > So by that logic, 80% of Hertz value is currently not trading. > > -- > ++ytti > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Contact at Ubiquiti Networks?
I disagree, Mel. Your quoting of exceptions, even if they were correct, doesn't invalidate the generalization that stock price is linked to product marketability. You can think of it in terms of data science: product marketability is a good predictor of stock price. On Wed, May 27, 2020 at 8:57 AM Mel Beckman wrote: > Hertz car rental has the #1 product in its industry, even its major > competitor Avis agrees (“We’re number two“:-), and yet Hertz stock is > plunging towards zero even as we speak. Stock price has nothing to do with > product quality. Theranos, for example, had a completely fictional product, > yet it stock price skyrocketed. > > Stock price is simply a way of measuring the perceived market value of a > company‘s earning potential. > > -mel beckman > > On May 26, 2020, at 11:50 PM, Etienne-Victor Depasquale > wrote: > > > " stock value is a terribly inaccurate way to measure if a company is > "excelling." " > > That requires qualification. > > Stock value might be a "terribly inaccurate way" in the short term but in > the long term, it reflects whether you have a marketable product or not. > > On Tue, May 26, 2020 at 4:20 PM Mike Hammett wrote: > >> Kind of OT for NANOG, but stock value is a terribly inaccurate way to >> measure if a company is "excelling." Wall Street knows nothing of how to >> run a company, prioritizing quarterly profit over long-term success. Not >> hiring additional staff makes your quarterly numbers look good, but it >> isn't good for the long-term attractiveness of your product. A good >> business doesn't just target new suckers, they also keep existing customers >> happy. Eventually you run out of suckers and all you have is a bunch of >> burned bridges in your wake. >> >> I subscribe to several feature requests in their community that are YEARS >> old with little to no response from Ubiquiti. Some of them can't be hard >> for Ubiquiti to implement because they're running on the exact same >> hardware and underlying OS and some of them you can configure in JSON >> files, but they just aren't available in the GUI. They just don't care. >> They'd rather push out Flavor Flav cameras or lighting. >> >> They came out with a new product in a particular family and opened a new >> feature request section for it. I commented something similar to, "Start >> with feature parity with the existing product, then start working through >> the years of feature requests there. Come back when you're done." >> >> >> This doesn't just afflict equipment manufacturers. Network operators are >> in the same boat. Both groups have companies profiting hundreds of millions >> or billions of dollars every quarter, can't spare a few hundred grand a >> year for a couple dev-ops guys to just bang out automation or features. >> Yes, I understand you rarely get twice the work from twice the people, but >> there are opportunities to make this better. >> >> >> >> >> >> - >> Mike Hammett >> Intelligent Computing Solutions <http://www.ics-il.com/> >> <https://www.facebook.com/ICSIL> >> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> >> <https://www.linkedin.com/company/intelligent-computing-solutions> >> <https://twitter.com/ICSIL> >> Midwest Internet Exchange <http://www.midwest-ix.com/> >> <https://www.facebook.com/mdwestix> >> <https://www.linkedin.com/company/midwest-internet-exchange> >> <https://twitter.com/mdwestix> >> The Brothers WISP <http://www.thebrotherswisp.com/> >> <https://www.facebook.com/thebrotherswisp> >> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >> -- >> *From: *"Matt Hoppes" >> *To: *"Mike Hammett" >> *Cc: *"NANOG list" >> *Sent: *Tuesday, May 26, 2020 8:28:52 AM >> *Subject: *Re: Contact at Ubiquiti Networks? >> >> Except, you could argue they are exceling. Stocks are going up up up, >> and folks buy the product. >> >> I really wish stock holders would ask the proper questions in the >> quarterly calls. >> >> On 5/26/20 8:53 AM, Mike Hammett wrote: >> > That is a big problem. In terms of their UniFi product line, there are >> > no reasonable alternatives. >> > >> > Upper management is the biggest problem. They have severe ADD. >> > >> > A ton of companies have these kinds of issues. They just plain don't >
Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
s defined explicitly in > RFC 6775; RFC 6550 does not really say much about addresses. > > > > Note that the RPL people have since proceeded to (at least partially) > embrace the host-router concept from the IP architecture; RFC 8505 is an > update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. > > > > I have CCed Pascal Thubert who, as a co-author to all three RFCs, > certainly will have another perspective on this. > > > > Grüße, Carsten > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
Hello folks, I'm not sure whether this is within scope as it regards LoWPANs ... please chastise freely and ignore if LoWPANs are out of scope. While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents. I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section. For example: (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS) (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550 (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops. Can anyone confirm or contradict this impression? Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Contact at Ubiquiti Networks?
; Agree 1000% with the sentiments expressed by Mike. > > > > Unfortunately despite much research I’ve been unable to find a suitable > > replacement vendor. All the other vendors seem to want to ram > > cloud-management down your throat which I absolutely do not want. My > > network, my control, not under the auspices of someone else’s magic > cloud. > > > > > > > > On 25 May 2020, at 21:21, Mike Hammett > <mailto:na...@ics-il.net>> wrote: > > > > The company has mostly fallen apart. Their sales are going up, but > > their responsiveness and customer support have been declining over > > the last five years. > > > > > > > > - > > Mike Hammett > > Intelligent Computing Solutions <http://www.ics-il.com/> > > <https://www.facebook.com/ICSIL>< > https://plus.google.com/+IntelligentComputingSolutionsDeKalb>< > https://www.linkedin.com/company/intelligent-computing-solutions>< > https://twitter.com/ICSIL> > > Midwest Internet Exchange <http://www.midwest-ix.com/> > > <https://www.facebook.com/mdwestix>< > https://www.linkedin.com/company/midwest-internet-exchange>< > https://twitter.com/mdwestix> > > The Brothers WISP <http://www.thebrotherswisp.com/> > > <https://www.facebook.com/thebrotherswisp>< > https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> > > > > > *From:*"j k" mailto:jskl...@gmail.com>> > > *To:*"NANOG list" mailto:nanog@nanog.org>> > > *Sent:*Monday, May 25, 2020 3:16:36 PM > > *Subject:*Contact at Ubiquiti Networks? > > > > Does anyone have a good contact at Ubiquity Networks? Finding a > > pattern I don't like. > > > > Joe Klein > > "inveniet viam, aut faciet"^ --- Seneca's Hercules Furens (Act II, > > Scene 1) > > "I never lose. I either win or learn" - Nelson Mandela > > > > > > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Friday Reminder: Web Site Security
+1 On Sat, May 16, 2020 at 4:44 AM Mike Hale wrote: > Big plus 1 to Bill's point. > > On Fri, May 15, 2020, 6:37 PM William Herrin wrote: > >> On Fri, May 15, 2020 at 4:25 PM Valdis Klētnieks >> wrote: >> > On Fri, 15 May 2020 12:15:13 -0700, "Ronald F. Guilmette" said: >> > > This is your helpful Friday reminder to always pay close attention to >> > > the security settings of all of the web sites under your >> administration. >> > > Otherwise, anonymous skript kiddiez could show up at any moment and >> > > deface one or more of your web sites. (It happens a lot.) >> > > https://ipv4.plus/ >> > >> > Just this week, I have seen an (unconfirmed) report that there is an >> organized >> > effort that's abusing SSH keys that lack passphrases - if they pwn a >> system and >> > find one, they go surfing it as far as they can. >> >> You may have missed the schadenfreude in Ronald's post. >> >> Give it a rest Ronald. You won. >> >> Regards, >> Bill Herrin >> >> -- >> William Herrin >> b...@herrin.us >> https://bill.herrin.us/ >> > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Applications of MPLS in the metro area
I started poking around to learn more about these use cases and came across this interesting extract <https://www.juniper.net/us/en/products-services/routing/acx-series/datasheets/1000397.page> : "Juniper Networks® ACX Series Universal Metro Routers are Juniper’s response to a shift in metro network architecture, where the access and aggregation layers are extending the operational intelligence from the service provider edge to the access network." Not long ago, I used to think of anything above layer 2 as "service provider edge" and further still (away from access), but the responses I've garnered are pointing at a metro network that widely implements MPLS and access and aggregation segments that are seeing implementation of L3 functions. Etienne On Tue, Apr 28, 2020 at 7:45 PM Aaron Gould wrote: > Yeah, I forgot earlier but I’m using EVPN/MPLS for DC interconnections now > also, for nicely integrating L2/L3 and host/machine level route preference > > > > MPLS in some ways is reminiscent of the ability to fire-off Smart-PVC’s > (SPVC/P) over an ATM (asynchronous transfer mode) network, and thus achieve > end to end virtual private connectivity without touching the intermediate > nodes (p nodes)…. Since the p-nodes just do label swapping (like vpi/vci > swapping in the atm analogy) > > > > In actuality, many of my “p” nodes, are also “pe” nodes J it’s all > about what it’s doing at that moment for what it is that we are talking > about > > > > -Aaron > > > > > > *From:* NANOG [mailto:nanog-boun...@nanog.org] *On Behalf Of * > adamv0...@netconsultings.com > *Sent:* Tuesday, April 28, 2020 10:46 AM > *To:* 'Etienne-Victor Depasquale'; 'NANOG' > *Subject:* RE: Applications of MPLS in the metro area > > > > Hi, > > So where the books talk about PEs -think of your metro nodes here > (basically converting the metro into an MPLS network -or making it part of > your existing MPLS core) (you might not have a classic design where PEs > hang off of P-Core nodes and might have just rings of PEs in your metro > area) > > And where the books talk about various L3VPN and L2VPN services that’s > basically what you can offer over your metro -now that it’s been converted > to a fully-fledged MPLS network. > > Ranging from multicast L3VPNs for 3PALY services through L2 p2p|p2mp|mp2mp > services for Dat-Center-Interconect, to network-slicing buzzword (cause > with VRFs and Traffic Engineering you can slice your metro area network > whichever way you like). > > > > adam > > > > *From:* NANOG *On Behalf Of *Etienne-Victor > Depasquale > *Sent:* Tuesday, April 28, 2020 2:44 PM > *To:* NANOG > *Subject:* Applications of MPLS in the metro area > > > > Hello ! > > > > I'm looking for what a network operator would consider a realistic > reference deployment of MPLS within the metro area network. > > > > By "realistic reference", I'm asking about what a network operator would > consider to be a typical, perhaps most common, application of MPLS > technology. > > > > From a bookish perspective, I understand MPLS well but have never > implemented it in the scope of my current field of study (metro area > networks). I would dearly like to get this "grounded" perspective from > anyone who might care to share it. > > > > > > Cheers, > > > > Etienne > > > > -- > > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > > Web. https://www.um.edu.mt/profile/etiennedepasquale > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Applications of MPLS in the metro area
Hello ! I'm looking for what a network operator would consider a realistic reference deployment of MPLS within the metro area network. By "realistic reference", I'm asking about what a network operator would consider to be a typical, perhaps most common, application of MPLS technology. >From a bookish perspective, I understand MPLS well but have never implemented it in the scope of my current field of study (metro area networks). I would dearly like to get this "grounded" perspective from anyone who might care to share it. Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
Re: Network configurations survey
Will you share the results? It would be good to know them. On Fri, Feb 14, 2020 at 7:07 PM Usama Naseer wrote: > Hi NANOG, > > We have often read that CDNs/CSPs optimize their networking stack > configurations (e.g., TCP, HTTP etc.) to meet their performance/service > requirements. > Please help us in exploring the configurations used in the wild by filling > us this short survey (<10 minutes): CDN network configuration survey > <https://forms.gle/vaGNC3gHxps3Esqs9> (https://forms.gle/vaGNC3gHxps3Esqs9 > ) > > *Background:* > There’s a plethora of protocols and configuration options (TCP congestion > control, initial congestion windows, HTTP version, HTTP options etc.) > available for networking stack to address a variety of realistic network > conditions and devices. Content providers mostly hand-tune the network > stack configurations to suit the needs of underlying networks and users. We > aim to improve the tuning by building a dynamic network stack that > delegates the choice of tuning configurations to a data-driven model and > uses the optimal set of configurations for individual networks. > > *Purpose of Survey:* > This survey aims to understand the networking configurations used > in-the-wild by network operators and the extent of configuration tuning > used to curate the networking stack according to the needs of underlying > networks. We also aim to understand the rationale that goes behind tuning > the stack to a certain configuration. > > We expect the survey to be filled by anyone involved with content > delivery, protocol designing, next-gen protocols or network infrastructure. > The survey and collected data are anonymous and the aggregate results will > be used as part of a scientific study. > > Thanks in advance and we look forward to your responses. > > Usama Naseer (Brown University) > > PS: We would appreciate if you could forward the email to other operators > who might not be a part of NANOG. > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
