Making interconnection agreements between networks more dynamic
Hello, We are a group of networking researchers from UFRGS, UCLouvain and KAUST. We are working towards an approach to make interconnection agreements between networks more dynamic. The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions. To accommodate the expected growth of traffic demands, network operators need to over-provision. Even so, operators miss the ability to quickly respond when facing unforeseen traffic demands, because agreements have static characteristics and changes could take days or weeks to be implemented. Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads. We are interested in collecting some anecdotal evidence that dynamic agreements could solve real-world problems. Has any member of the forum faced any scenario where the kind of dynamism described above could be helpful? Many thanks for your inputs, -- Pedro de Botelho Marcos PhD Student Computer Networks Research Group Federal University of Rio Grande do Sul - UFRGS
Pedro de Botelho Marcos wrote:
The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions.
i'm not sure the available data supports this conclusion:
http://berec.europa.eu/eng/document_register/subject_matter/berec/download/0...
which notes:
Of the total analyzed agreements, 1,347 (0.07%) were formalized in written contracts. This is down from 0.49% in 2011. The remaining 1,934,166 (99.93%) were “handshake” agreements in which the parties agreed to informal or commonly understood terms without creating a written document.
Nick
On Tue, May 23, 2017 at 3:02 PM, Nick Hilliard <nick@foobar.org> wrote:
Pedro de Botelho Marcos wrote:
The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions.
i'm not sure the available data supports this conclusion:
http://berec.europa.eu/eng/document_register/subject_ matter/berec/download/0/6574-2016-survey-of-internet- carrier-intercon_0.pdf
which notes:
Of the total analyzed agreements, 1,347 (0.07%) were formalized in written contracts. This is down from 0.49% in 2011. The remaining 1,934,166 (99.93%) were “handshake” agreements in which the parties agreed to informal or commonly understood terms without creating a written document.
it's totally possible that the OP was not talking about "peering" as interconnection (entirely) but also 'customer interconnect' as interconnection. So... "I have 1gbps of traffic I need to send to elbonia-telcom (today) , and tomorrow maybe 3?" means provision a 10g link with 1g commit and burst at X cents/mbps... or whatever... and that works 'today'. Tomorrow you realized 'whoops, by 3gbps I really meant 13... err, now I need to provision a 100g link or add another 10g and LAG... which means 90day telco turnaround on link provisioning... -chris
This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get there one day. Sounds like a lot of initial cooperation -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Pedro de Botelho Marcos Sent: Tuesday, May 23, 2017 1:07 PM To: nanog@nanog.org Subject: Making interconnection agreements between networks more dynamic Hello, We are a group of networking researchers from UFRGS, UCLouvain and KAUST. We are working towards an approach to make interconnection agreements between networks more dynamic. The current approach for establishing agreements is cumbersome, typically requiring lengthy discussions. To accommodate the expected growth of traffic demands, network operators need to over-provision. Even so, operators miss the ability to quickly respond when facing unforeseen traffic demands, because agreements have static characteristics and changes could take days or weeks to be implemented. Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads. We are interested in collecting some anecdotal evidence that dynamic agreements could solve real-world problems. Has any member of the forum faced any scenario where the kind of dynamism described above could be helpful? Many thanks for your inputs, -- Pedro de Botelho Marcos PhD Student Computer Networks Research Group Federal University of Rio Grande do Sul - UFRGS
This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get there one day.
to me, this was the dream of optical switching and gmpls (which is not mpls) randy
This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get there one day.
to me, this was the dream of optical switching and gmpls (which is not mpls)
And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel? Reminds me of the old days when you could directly connect "Chicago" to "Denver" using a direct connection over a PVC that was routed Chicago -> New York -> Miami -> Los Angeles -> Denver. Sure, it looks like a direct connection, but ... Or will this magical interface also deploy robots to build the physical layer?
to me, this was the dream of optical switching and gmpls (which is not mpls) And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel?
read "which is not mpls" a few more times. than maybe read a bit on gmpls and optical switching. you may find https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching a reasonable place to start. randy
to me, this was the dream of optical switching and gmpls (which is not mpls) And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel?
read "which is not mpls" a few more times. than maybe read a bit on gmpls and optical switching. you may find https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching a reasonable place to start.
Ok, but does this still not pre-suppose that an appropriate physical path that has sufficient available bandwidth/slots is already present?
read "which is not mpls" a few more times. than maybe read a bit on gmpls and optical switching. you may find https://en.wikipedia.org/wiki/Generalized_Multi-Protocol_Label_Switching a reasonable place to start. Ok, but does this still not pre-suppose that an appropriate physical path that has sufficient available bandwidth/slots is already present?
not *a* physical path, but a swath of paths from which sufficient capacity can be configured. sadly, gmpls over optical has not yet defied the laws of physics. randy
This sounds something like the MEF Third Network type stuff.... I mean the ability to setup connection dynamically across network boundaries on-the-fly, via an ordering system... that has always sounded awesome to me... and I've wondered how we could actually get
Sdn/nfv for the physical layer... c'mon man, don't you know we are going to have virtual-fiber too , LOL , jk of course -Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Keith Medcalf Sent: Tuesday, May 23, 2017 5:52 PM To: nanog@nanog.org Subject: RE: Making interconnection agreements between networks more dynamic there one day.
to me, this was the dream of optical switching and gmpls (which is not mpls)
And, pray tell, what is the use of me setting up "peering" between myself and a network on the other side of the world when the data still has to flow over the same connections, merely encapsulated inside a tunnel? Reminds me of the old days when you could directly connect "Chicago" to "Denver" using a direct connection over a PVC that was routed Chicago -> New York -> Miami -> Los Angeles -> Denver. Sure, it looks like a direct connection, but ... Or will this magical interface also deploy robots to build the physical layer?
On Tue, 23 May 2017 15:07:14 -0300, Pedro de Botelho Marcos said:
Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads.
In computer science, all problems can be solved by adding a level of indirection. You've now changed it from lengthy discussion about the connection, to lengthy discussion about which dynamic agreements both sides are willing to support. Hint: You can't discuss "bandwidth as a service" without both sides talking about how much burst capacity might be needed, because the capacity would *still* require over-provisioning in order to be available if needed. If both ends of the link have 1G optics, you're not going to burst to 10G no matter how many dynamic agreements you have.
You need an extra 9 lines to handle the overrun. On May 23, 2017 12:10:52 PM PDT, valdis.kletnieks@vt.edu wrote:
On Tue, 23 May 2017 15:07:14 -0300, Pedro de Botelho Marcos said:
Dynamic agreements offer many opportunities. For example, consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it, similarly to how one might spin up extra VMs in the cloud to handle high loads.
In computer science, all problems can be solved by adding a level of indirection.
You've now changed it from lengthy discussion about the connection, to lengthy discussion about which dynamic agreements both sides are willing to support.
Hint: You can't discuss "bandwidth as a service" without both sides talking about how much burst capacity might be needed, because the capacity would *still* require over-provisioning in order to be available if needed. If both ends of the link have 1G optics, you're not going to burst to 10G no matter how many dynamic agreements you have.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On May 23, 2017, at 2:07 PM, Pedro de Botelho Marcos <pbmarcos@inf.ufrgs.br> wrote:
consider acquiring extra "bandwidth as a service" that is available on demand just when one needs it,
Wasn't this the initial promise of SDN? Hand wave. Magically connected endpoints. All QoS'd and bandwidth-guaranteed configuration completed perfectly every time across disparate networks/equipment.
participants (9)
-
Aaron Gould -
Christopher Morrow -
Keith Medcalf -
LHC (k9m) -
Nick Hilliard -
Pedro de Botelho Marcos -
Randy Bush -
Steven Tardy -
valdis.kletnieks＠vt.edu