Welcome to AWANTA Discussions!

[pradeeban]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[Rinceri]

Hey there!

I am Divyansh, a first year university student, and I find the use of technology for researching into novel approaches to aid other fields intriguing. I hope I can make meaningful contributions to this project; it excites me with what the project involves.

For context, I learnt about this organisation through GSoC, and hope to meet other contributors and the mentors on this project!

From what I understand, this project aims to build a router that uses optimal paths to route data in regions with poor network connectivity, is that correct? Is there any way I can get familiar with AWANTA, and get hands-on experience with its fundamental libraries/projects?

Cheers!

[Vamsi995]

Hi @Rinceri,

I can try to answer some of your questions.

For the first question, I think we need to prepare the set of probes and destination parameters for traceroute measurement and send it as a payload with the auth key (RIPE API KEY) as header to https://atlas.ripe.net/api/v2/measurements endpoint. These will be registered as measurements in the portal https://atlas.ripe.net/measurements/public?id__gt=1000000&is_public=true&sort=-id&toggle=all&page_size=100&page=1 which performs the measurements for us. And based on how many sets of parameters you send, those many number of experiments are created. I think the number of hops are important measure of network performance in real-time, and would be better if it's a lower number.

For the second question, I think this would be a network overlay, and the data nodes will communicate with other data nodes in the WAN.

@pradeeban please let me know if I am correct.

[pradeeban]

@Vamsi995 is right. Thanks for the answer.

I would say mean latency (time series, rather than latency at any spot. Perhaps, using a heuristics) more than number of hops. Likely, a combination of both.

[Rinceri]

Thanks @Vamsi995 @pradeeban!

Is it possible I can run multiple traceroute measurements? So I can observe path changes (along with variations in number of hops and their effect on the latency) between two probes. I do not have RIPE credits either, to run any measurements.

[pradeeban]

Hi @Rinceri, yes, you can. There are some limits on how many measurements you can run per user account, and per hour or day. Other than that, yes, we always run multiple measurements in parallel.

If you create a RIPE Atlas account and share with me the email address that you created the account with, I can transfer some credits for you to try these.

[Rinceri]

I have registered an account with this email address: jaindivyanshworks@gmail.com

Thanks.

[Vamsi995]

Hi @pradeeban,

I am Alisetti Sai Vamsi, a Computer Science graduate from IIT Palakkad. I stumbled upon AWANTA, which instantly caught my attention. Its potential to revolutionize telehealth in healthcare deserts with limited internet access fascinated me deeply. Witnessing how technology could directly impact and potentially save lives is truly remarkable. I also have a strong background in Python programming, and I have a preliminary Computer Networks background, because of the networking course that I took in college, where I learned about, subnetting, MPLS, TCP/UDP, ASes, Routers, Switches, etc, and worked with the CLI tools in Linux to analyze networks, but never had the chance to work on designing an SDN/SD-WAN.

Participating in this project, I aspire to not only contribute to AWANTA but also acquire invaluable skills in SDN/SD-WAN design. This experience aligns perfectly with my passion for leveraging technology for societal betterment, particularly in critical domains like healthcare. I am looking forward to the possibility of contributing my time to build this system with guidance from the mentors.

I have gone through the paper mentioned in the repository and this is my understanding of it.

The data node of AWANTA consists of a decentralized RIPE client, that checks the internet quality/variations, which if found, triggers an event to the control node of AWANTA, to decide on a new route to find.

The control node of AWANTA, consists of the event broker, to handle events from the data nodes, and also houses the SD-WAN controller, that performs the control plane routing decisions.

Please let me know if I misunderstood any detail, and can you please guide me on what to get started on first?

Regards,
Alisetti Sai Vamsi

[pradeeban]

Hi @Vamsi995, I like your thought process on the design. This is a great start.

The design is flexible since we are in the early stages of development. SDN and similar "network softwarization" approaches (or approaches inspired by those in the WAN) help us to make the paths programmable through regular user-facing APIs or through network parameters (such as congestion and QoS demands).

Going through Ryu SDN controller is a good start to understand SDN. Another point to note is that the SDN is a fast-evolving field. But it is also reaching stability now that it has been around for longer than a decade. You may even find a simpler or better SDN controller from recent days (I have evaluated OpenDaylight, Floodlight, ONOS, and Ryu. Ryu was the easy to use one among all these).

Good luck with your research.

[Vamsi995]

Hi @pradeeban,

I delved into the Ryu SDN framework, immersing myself in its architecture and comprehending its role in orchestrating network flows within switches compatible with the OpenFlow protocol. My exploration extended to grasping the theoretical underpinnings of OpenFlow, including pivotal concepts such as Flow Tables, Group Tables, and OpenFlow Channels.

I gained a solid understanding of how Flow Tables operate, leveraging matches and actions to dynamically manage network data paths. Building upon this understanding, I successfully developed a functional SDN L2 switch controller using the Ryu framework, establishing seamless communication with an Open vSwitch and simulated hosts via Mininet. I played around with the configurations in the Ryu Framework and understood the nuances of the SDN controller.

Moreover, I went through the RIPE Measurement project that you mentioned and explored the traceroute and ping measurements that are present in the repository, however, I would have loved to see it happening in live, but because of the absence of the RIPE API key, it's not possible.

Coming to the design of the whole project, I have a few rudimentary questions that I am confused about:

1. Internet Measurement Standard: What is the Internet Measurement standard that we will be using? Is it based on the RIPE measurement that uses ping and traceroute to provide us the average round trip time, and number of hops based on the destination of the packet? Is this the measure of good/bad internet and the heuristic for a data path change? For example: Let's say we have an AWANTA node that is connected to the host, and let's say it receives data to transmit, now the packet will have the destination IP, does the RIPE client now measure the internet quality by pinging this destination IP and performing a traceroute to this IP? If not how does it assess internet quality? And also how can we leverage results from broadbandmapping.com on a more granular (router level) level?

2. About the Cloud Router: As far as I know, this cloud router needs to support the Open Flow Protocol, and needs to be treated as a L3 switch. Are we going to develop this cloud router ourselves, if so what libraries are we using to build this switching application?

Regards,
Alisetti Sai Vamsi

[pradeeban]

@Rinceri, I am enjoying this conversation. :)

Yes, sadly many SDN controllers have gone into an idle unmaintained stage. I think there was a time of a hyped research curiosity around SDN controllers. Now SDN is mature and an industry-wide standard, so it is not a research curiosity anymore.

Combined with that is the fact that my own experience with SDN controllers is largely stuck at 2019. So, the frameworks I am proposing are probably outdated, as you could imagine. I had a group of students who successfully configured Ryu for a demonstration. So it works. But they had to use some specific version of dependencies.

os-ken looks promising with more recent updates. Sounds like a good find to me.

Yes, good idea in your proposal. The approach you propose minimizes the reliance on the measurements (which are throttled by RIPE) and optimizes the framework overall in terms of scalability and performance too (I believe! we should benchmark to be certain).

[Vamsi995]

Hi @Rinceri ,
I built the image from the source, instead of using pip package manager directly. I read their README page as well which mentioned that Ryu was no longer maintained, and suggested using os-ken instead. Its a fork of the Ryu project, so the entire codebase is quite similar, except for a few minor details. Also the documentation is a bit flaky, thats why I steered away from it. However, we can use either one of them because the API interfaces they expose are the same.

For the second part, I think its a good idea, however I first want to evaluate the time/latency it takes for the RIIPE client to make measurements, and want to understand the whole structure of these RIPE client measurements before I go into ideation phase. Also neighbour discovery and sharing, also imposes additional bandwith requirements, so we might have to look into that as well.

[Vamsi995]

Hi @pradeeban,
Thank you for your response. My registered email address to the RIPE NCC portal is saivamsi.ds123@gmail.com.

I wanted to get access because I want to measure the amount of time the RIPE client takes to provide the Average RTT.

Based on this I have two train of thoughts in my mind:

1. Active Probing: If the RIPE client results are very fast, we can think of a real time probing unit, inside the SDN controller itself to setup reactive flows during PACKET OUT messages based on these measurements.

2. Passive Probing: This is similar to what @Rinceri mentioned, we can do neighbour discovery on the machines, and setup proactive flows initially at startup to get the underlying network architecture. Then based on periodic probing on each node, we can setup reactive flows, using a shortest path algorithm or any control learning policy.

3. Expectations of the project: As you said @pradeeban, building for an open source project of this scale is quite new to me, so here is my plan for the project:

   • P1 - Research on Internet Measurement - Find the factors that can properly assess the internet standard quality. (RIPE client can be used initially). Build a barebone package that can perform measurements.
   • P2 - Building the testing environment - Building out the topology virtually using OVS, and Mininet, and conducting traffic tests using iperf to simulate real-time traffic.
   • P3 - Simple Algorithm on SDN - Start with the simple model of using reactive flows, to dynamically send out packets to the desired neighbour, based on the RIPE client measurements sent to the controller node during PACKET IN mesesage. From here we can build out our logic and make it increasingly more complex.
   • P4 - Ideation Phase: Once the infrastructure and the basic algorithm is setup, we can look to innovate and ideate on the type of algorithms and measurement strategies that can go into the project. One idea on the top of my head, is to build the topology virtually in the SDN controller and use shortest path algorithms to add the necessary flows to route the traffic effectively.
   • Hopium - Create a PPO/DQN reinforcement learning value-based and policy-based control policy in the SDN controller and train it using the state of the network topology, and create an action policy to create flows directing switches across the network to route the packets efficiently and write a paper on this.

@pradeeban what do you think?

Regards,
Alisetti Sai Vamsi

[Vamsi995]

Also @pradeeban, on a completely different note, I was also looking into the project of beehive, and I was wondering why not use vector databases (they offer semantic understanding of the pictures and you can prompt images based on text input rather than just keyword classification) instead of traditional NoSQL, and SQL databases.

Regards,
Alisetti Sai Vamsi

[pradeeban]

@Vamsi995 this is a great idea regarding the vector database. Just didn't cross our mind when we wrote the idea. Now I don't want to change it in the ideas list given this is already announced. But for sure include that in your proposal (if you are submitting to that idea as well).

On the RIPE Atlas front (coming back to the topic!), your 10,000 credits have been transferred. Feel free to ask for more.

Remember, we are building a community as a new Google Summer of Code organization, and your contributions are already appreciated and valued.

Your proposed plan sounds fantastic. Definitely something you could work on as a first-author paper(s).

There is a "Community Bonding Period" as part of the GSoC, where the contributors could utilize to discuss more. We have one-to-one meetings with the accepted contributors.

Regarding your PI, yes, broadbandmapping.com and Alaska Native Tribal Healthcare Consortium (ANTHC) follow a similar approach. You can search for those and find inspiration.

P2: Yes, the simulations and emulations are the realistic approach, if you ask me, if I were to do this during the summer. But I won't discourage anyone from planning big. The huge challenge would be the resources (cloud computing costs money and we do not have credits

P3: Sounds like a plan. Once it is functional, we can always replace it with better-performing algorithms taken from the literature. (we don't have too much time to make the best-perfoming algorithm to overtake the state of the art. It is a 350-hour project.)

P4: Yes, we could open up more avenues that can sustain the platform for future developments.

[Rinceri]

Hey there @pradeeban!

Since the GSOC application window is opening soon, I was drafting my proposal and had a couple of doubts:

1. Would the research part of the project (i.e. the internet measurement experiments observing paths) be a part of the 350 hours?
2. The GSOC page states that i need to do a "code challenge". Would this just be presenting any examples where I have used Python before (perhaps linking a Github repo of a project in Python)?
3. In the expected outcomes for the project, contributors are (explicitly) only expected to work on the RIPE measurements client and a virtual router. So would we work on the controller and event manager?

Also, out of curiosity, how would the data nodes be deployed on our overlay network? Would it be, for example, on public cloud servers?

Thanks,
Divyansh

[pradeeban]

Hi @Rinceri,
Nice to hear from you.

1. The 350 hours is the coding period, which includes the research. We follow somewhat of an Agile approach, refining the design as we go researching. But also you have the one month of community bonding period. It does not come under that 350 hours. But we usually meet the contributors weekly (if they are available), for like up to an hour. Then you may want to spend sometime understanding the tech before the coding period starts. So, I would say minimum of 2 hours a week during the community bonding period, although most contributors end up spending much more depending on their examinations and other commitments.
2. You got that right.
3. My generalized concern about new projects is, often we underestimate how much it takes to build a research framework. The client and virtual router are required parts of the project. You can include the controllers and event managers as optional. Remember, you have plenty of freedom in your proposal. Just make sure you have them all realistic, given it is actually just 350 hours of coding. While you are free to stick around after the deadline, we want to make sure we have something that works by the end of the GSoC coding period.

That is right. That is how we have usually managed this. We might be having challenges with the cloud credits (the data transfer across regions cost a lot of money, in addition to the cloud instances themselves). We might be able to reach out to Google for GCP credits, although that is not guaranteed.

[Rinceri]

Thank you for the clarification, it is really helpful, but I had a further question on point 1:

I was wondering, in the expected outcomes for the project it is mentioned that we would observe how the network path changes with time, and that we have enough credits to run these experiments. This led me to believe that the project will involve doing these experiments and documenting them as part of a research paper perhaps. If that is correct, would we be allocating any time to this activity?

[pradeeban]

Yes, For credits, we have 65 million and I accumulate credits every day. So, we will not be running out of credits for sure, in this scale.

You can allocate regular documentation time for the research paper. Given the limited time, we shouldn't be losing time for the development either. When you have a proposal, I can comment on your timeline.

[Rinceri]

Thank you very much.

[Vamsi995]

Hey @pradeeban,
I was trying to use the measurement API, in the RIPE Atlas NCC portal. When I was trying to ping my IP address it was not able to provide the results.

Do you have any idea why?

Is it because there are no ASes that connect to my region?

Regards,
Alisetti Sai Vamsi

[pradeeban]

Private hops are those intermediate nodes that are in a private network. Total hops include both those private and public IP addresses.

The path can vary, so yes, the number of hops will vary. But it is not as frequent. Often, the path will stay the same throughout your day-long experiment. In any case, that is why we observe for the whole day, rather than doing a one-off measurement.

Same is true for end-to-end latency (measured through ping). You don't want to take a one-off measurement. You need a series of measurements (with time intervals), so you have a reliable estimate.

The alternating paths also show the existence of multiple potential paths, which is good.

[pradeeban]

I like your questions. Those are meaningful ones.

You highlight one major limitation of our approach. That is, we are not in the power of changing the Internet path at a global level, since we are not deploying our solutions at an Internet-Service Provider (ISP) level or at an Internet eXchange Point (IXP). Means, we are largely relying on an overlay network, where each node is connected to other nodes (thus, providing multiple paths).

The idea is to have the potential to measure the network performance in real-time and dynamically change the path. WIth those in place, we can then see how can we get this to provide better performance in real-time through network nodes that do not belong to us. (Otherwise, if we are limiting ourselves to our nodes - as in a cloud transfer you could do across AWS nodes, we are going for a sub-optimal solution). But I see this more as the first step towards a functional solution, rather than one that outstands the state-of-the-art.

I am sure a reviewer would easily say that we are not doing anything novel. But that is fine. We are making a complete open source framework of something that is done in research or through closed-source solutions.

Does that make sense?

[Rinceri]

How would we use network nodes that don't belong to us in our overlay network? That is, how would the virtual routers of AWANTA recognise that these external nodes exist?

I had the idea that we would do traceroute measurements to find the fastest path, and take advantage of overlay nodes to modify our network path. Below is a simplified diagram of my understanding.

I believe traceroute measurements may not take these nodes as part of the route (only RIPE probes), and so we may need to identify the closest next node, in which case I think it should be faster to periodically perform these measurements and take the path based on the last measurements and calculations.

This should be faster than regular routing, which doesn't really look for the shortest route, and is affected by policy issues.

[pradeeban]

You both are looking into the actual deployment and the practical challenges - which is great.

For the implementation standpoint, we will need to make some assumptions. That is, the solution runs in a fully connected network (so, multiple paths exist and they all can measure the performance through the RIPE Atlas or share their measurements to/from other nodes).

"How would we use network nodes that don't belong to us in our overlay network? That is, how would the virtual routers of AWANTA recognise that these external nodes exist?"
The existence of external nodes and having to consider them into the policy decisions is possible but will get the task a bit more complicated than something that can be achievable in 350 hours. Furthermore, we cannot and do not assume the ability to deploy the solution at an Internet Service Provider (ISP), which will otherwise give us greater potentials (for instance, in peering with other Autonomous Systems). For example, a previous project I worked on was - https://dynam-ix.github.io/, which assumes the potential for deployment in an Internet eXchange Point (IXP).

As long as these nodes "advertise" their existence we should be able to leverage those external nodes too. But without something such as a data receiver/router in their end, we won't be able to freely move data around.

Just to clarify, while that is indeed our goal, we cannot claim "faster than regular routing" yet. Sometimes random routing (classic BGP) would outperform explicitly moving data around (especially if we have a little overlay and we force all the data to go through those or if our router adds more delay than what it can save). And that is okay. Once we have an open source prototype, we can optimize on that further.

An approach I have done before was, observing whether a better performance possible, and if not, just let the classic public-Internet-based routing, rather than using our overlay. (At this point, what overlay we use is questionable. In the past, I have used AWS instances and an overlay on top of that.)

Remember, there are multiple potential paths and no right or wrong architecture at this point. Both of your architectures and approaches are valid and feasible.

[Rinceri]

Understandable. My diagram just builds on Vamsi's architecture, and showcases one way of using it.

[Vamsi995]

Hey @pradeeban,
I want to understand how we are going to utilize cloud routers. For the simulations, are we going to create a VPC and then perform traffic tests on there, if so how will we utilize RIPE atlas there. Or are we going to use cloud routers as a proxy which tunnels the response to the peer network.

[pradeeban]

Right. We will have a custom Image (such as an Amazon Machine Image / AMI) with our Cloud Router installed. It is a virtualized network. I wonder, in practice, given an overlay network, whether we will really use Ryu though. It is more likely a virtual router, rather than an SDN controller such as Ryu. In a hardware network (where WE control the servers, this makes sense).

From Architecture standpoint, what you draw makes sense. I am still trying to see how do we handle "Non AWANTA nodes" or do we simply assume all the nodes to be "AWANTA nodes" at this point. The latter probably makes the problem less complex.

[pradeeban]

Missed your first question:
The one problem is: the implementation question. Can this be achieved with sufficient number of servers at our disposal to route traffic around.
The other one is: the deployment question. At this point - yes, if we deploy this with the limited resources we have, of course, we are not getting any practical performance enhancements. But we can think of a future deployment (or even when we have lots of cloud credits to deploy this across cloud regions).

I see the GSoC application deadline is April 2 - 18:00 UTC.

Do you like to have a quick Zoom call to discuss and clarify your doubts?
Will April 1st Monday any 1 hour between 8 am - 10 am AKST (it will be night time in India) work for you? Let me know your preferred time slot (if you are available, that is) and your email address. I will send an email invitation.

That way, we can clarify all the questions at once. :)

[Vamsi995]

Hi @pradeeban, can we meet today? If it is okay with you, I will be free from 8pm IST to 11pm IST. saivamsi.ds123@gmail.com is my email address. Please let me know if you will be free today, otherwise tomorrow same time is also fine.

[pradeeban]

Hi @Vamsi995, I am traveling for project meetings these days and cannot make a call these days.
Monday April 1st, 8 am - 12:30 pm Anchorage time would work for me. This is not a mandatory meeting, and we do not usually have Zoom meetings during the application period, except in exceptional cases when we think a meeting could clarify doubts better. If Monday does not work, do not worry about the meeting. We can continue the conversations with your proposal submission in text, as needed.

In any case, please make sure to submit your proposal on time well before the deadline.

[pradeeban]

@Vamsi995, pls note the coding period requires 35 hours/week commitment for the 10 weeks. (350 hours of effort).
I would recommend that your proposal indicate that as such (or slightly more, if you want to). But suggesting a lower time commitment usually will flag something. These projects indeed require 350 hours of coding+designing effort during the coding period. Just to make sure we are not underestimating the complexity/difficulty of the task. :)

Other than that, great proposal.
We will have a weekly Zoom/Skype (Alaska morning times are ideal) with the contributor. So, indicating your preference to Zoom or Skype would also help.

[Rinceri]

Hi @pradeeban, I was wondering whether I should email the draft proposal or just send it here (I don't mind keeping it open source :) ), as I wanted you to comment on it.

Also, I too am a little confused by how we will be implementing the AWANTA framework, as part of GSOC.

My idea is, according to the GSOC expected outcomes, the cloud router would be in every node, that would use the RIPE measurements to dynamically decide on the next hop (i.e. to the next node or to the destination), rather than just store the flow table installed by an OpenFlow controller. That is, the software router would contain the control plane and data plane (rather than just the data plane).

I don't think this would be an SDN as such, since there is no separation of a centrally managed control plane and the data plane, but would work as a first implementation, and considering the time limitations.

[pradeeban]

You could email or post it here - both are ok with me.

We are probably heading towards an SDN-inspired architecture (an SD-WAN), rather than an SDN itself, as we are dealing with a wide area network managed by several entities, rather than a single network.

If you like to discuss over the Zoom, I can meet you between Monday April 1st, 8 am - 12:30 pm Anchorage time. Just choose a 30 minutes timeslot and provide your email address.

At this point, my recommendation would be to submit your proposal with your understanding. (The deadline is fast approaching on April 2nd).

[Rinceri]

Hi @pradeeban

Understood.

Here is my draft proposal: https://docs.google.com/document/d/1umsXTtOfIcZGp_gw_PqY0JvYJln3a7DDCSIjJgF7qNs/edit?usp=sharing

Could you kindly review it? Sorry for finishing so late, I had to juggle with some courseworks :)

If you think the idea/plan I have described in the proposal is different from how the expected outcomes must be achieved (or you feel I haven't exactly understood the framework), we can do a Zoom meeting at 9 AM Anchorage time, if that is convenient for you.

[pradeeban]

No worries. Looks ok to me.

Usually, I recommend breaking down the tasks to one-week intervals. But with the heavy research and volatile nature of this project, I think it is ok as the way you have drafted.

We use Zoom or Skype for weekly meetings during the GSoC coding period. Please indicate your preference for one of these.

I don't think we need to meet before the deadline. Your proposal looks fine. Pls make sure to submit it in the official GSoC site.

[Rinceri]

Thanks. I have broken it down with pointers for the tasks to do per week where ever I have grouped more than a week together, but for the sake of clarity I will explicitly break it down per week, as that was my intention.

[Rinceri]

Hey there!

I found out my proposal was rejected. I realised it would be difficult getting in considering my limited knowledge but if you have any feedback or comments regarding my proposal or anything else I would really appreciate it, so I can learn from my mistakes and improve for next time. Thanks.

Also, congratulations @Vamsi995!

[pradeeban]

Hi @Rinceri,
Your proposal was great.

It was two reasons we could not accept all the excellent proposals.

1. Our low acceptance rate (8%). We cannot accept all the great contributors, due to lack of mentors and lack of slots (we received 4 slots).
2. Sometimes, we have to choose the better candidate for the project idea among two (or more) great candidates. We cannot accept more than one candidate for a project idea.

But we appreciate all your contributions so far. I am sure @Vamsi995 enjoyed the discussions he had over here with you as well.

Thank you.