Welcome to L4SBOA 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.

[Jeffrin2005]

@pradeeban Hi,
My name is Jeffrin Jojo. I would like to contribute to Alaska organization. I am currently learning Full Stack Development, TypeScript, and Python Django development and interested in collaborating with the Alaska organization.

Could you let me know if L4SBOA is a continuation or improvement needed project of L4S for GSoC 2025?
What are the expected ides for GsoC 2025?

Thank You 😊

[pradeeban]

@Jeffrin2005 the project that is implemented for GSoC 2024 is largely a basic prototype. So, most work in the project idea is left to be implemented. The already listed idea should give some hints. We will likely update it further in mid January.

[ASHISH-JHA94]

Hello @pradeeban,
I hope you're doing well. I am eager to contribute to the Alaska organization and its impactful projects. I have extensive experience working with React, Python, and Java, along with strong skills in both frontend and backend development.
I was particularly interested in this repository and would like to know if there are any open issues or specific areas where I can contribute.

[saksham-gera]

I seeks permission to extend the scope of the L4SBOA project, focusing on:

1. Validation of L4S in Telehealth Deployments:
   • Investigating the applicability of L4S for telehealth scenarios such as DICOM image transfer, real-time monitoring, and teleconsultations.
   • Examining how L4S interacts with traditional non-L4S traffic in mixed network environments.
2. Prototyping and Evaluation:
   • Developing L4S-enabled endpoints for telehealth using a Linux kernel with L4S patches.
   • Testing DICOM image transfer between two endpoints as a starting point, scaling to real-world telehealth deployments.
3. Addressing Telehealth Needs in Alaska:
   • Improving telehealth access for underserved communities with an emphasis on mitigating latency, loss, and throughput challenges in rural areas.
   • Engaging with ANTHC and other partners to tailor solutions for their operational needs.

Proposed Roadmap:

Phase 1: Infrastructure Setup and Initial Tests 
 •	Goal: Deploy and evaluate basic L4S capabilities in controlled environments.
 •	Set up a pair of L4S-enabled endpoints using Linux kernel patches.
 •	Test DICOM image transfer between endpoints under controlled network conditions.
 •	Benchmark L4S performance against classic congestion control protocols (e.g., TCP Cubic, BBR).

 Phase 2: Application Integration 
 •	Goal: Develop L4S-based prototypes for diverse telehealth applications.
 •	Extend testing to telemonitoring and video calls.
 •	Address intercompatibility between L4S and non-L4S traffic.
 •	Incorporate telemetry for performance monitoring and analytics.

 Phase 3: Deployment in Telehealth Scenarios
 •	Goal: Validate L4S performance in real-world telehealth deployments.
 •	Collaborate with ANTHC to test L4S in practical scenarios (e.g., patient consultations, monitoring, diagnostics).
 •	Measure impact on key metrics: latency, loss, throughput, and user satisfaction.
 •	Identify and implement optimizations based on deployment feedback.

 Phase 4: Documentation and Dissemination
 •	Goal: Publish findings and propose a scalable telehealth framework.
 •	Compile a comprehensive report and recommendations for deploying L4S in telehealth applications.
 •	Present results at relevant conferences or journals.
 •	Engage stakeholders for future collaborations and funding opportunities.

[saksham-gera]

Hey @pradeeban , could you please share a detailed roadmap or clarify your expectations for this project? Understanding the scope and key objectives will help me align my work properly from the start. Let me know any specific deliverables or milestones you have in mind!

[pradeeban]

@saksham-gera I like your proposed vision. See how you could utilize and extend the currently implemented L4S simulation prototype (in the L4SBOA repository).

[saksham-gera]

Thank you! I’ll review the current L4S simulation prototype in the L4SBOA repository and explore ways to extend and optimize it.

[ASHISH-JHA94]

The L4SBOA project is a React-based frontend application designed for telehealth use cases, such as video consultations, DICOM image uploads, and wearable device data integration. Currently, the project only has a frontend structure, and I need guidance on setting up the backend to support L4S (Low Latency, Low Loss, Scalable Throughput) nodes for network optimization.

The backend should handle:

• Communication between L4S nodes for low-latency data transfer.
• Integration with telehealth features like video calls, DICOM image processing, and wearable device data.
• Coexistence with non-L4S traffic.

I’m unsure about:

• Where and how to set up L4S nodes.
• How to integrate L4S nodes with the frontend.
• What backend technologies or frameworks to use.

can you little elaborate about backend.

[pradeeban]

Some simple backends such as DICOM senders/receivers (for example, Orthanc PACS) can be an easier goal. Setting up L4S nodes is basically, patching the Linux kernel with L4S (check for how Kolawole did this last GSoC following the public documentation from L4S).

The L4S nodes themselves are essentially, patched Linux servers. So, integrating with frontend is like integrating with regular TCP-based communication in Linux. (i.e., no additional steps would be necessary once you have L4S in place of classic TCP).

[Aditya08Vashisht]

Hello there, I am very keen to work on this repo.. but facing this..??

as i go for "Go Live"
how can i run it locally

[pradeeban]

@kolawolecreates Do you have any pointers on what is going on in this issue?

[Aditya08Vashisht]

I feel like the mentors should give their respective commands to run it locally from the terminal side

[pradeeban]

The command is here: https://github.com/KathiraveluLab/L4SBOA/blob/main/L4SkernelPatchSetUp.md

There is a pull request to improve the commands further - #22

[ASHISH-JHA94]

@Aditya08Vashisht ,this is not the way of running react project,
you should first do
1> npm i
2>npm start

[ASHISH-JHA94]

@Aditya08Vashisht ,this is not like simple html that you have tried to run directly in public/index.html,if you encounter any error feel free to discuss.

[pradeeban]

@ASHISH-JHA94 thank you for your reply. When you have time, can you open a pull request to add commands to README.md, specifically to include

you should first do
1> npm i
2>npm start

and any additional details to help new developers get started?

[ASHISH-JHA94]

Sure,I will do.

[Aditya08Vashisht]

@ASHISH-JHA94 i have also done that still the issue is same let try it after some hours as I’ll try some other commands as well….

[ASHISH-JHA94]

@Aditya08Vashisht ,we have updated readme.md once look on it.

[pradeeban]

Dear All,
Please note (as explained in the project ideas page), this is an L4S Linux and networking based project. But most of these discussions are evolving around the minimal front-end that @kolawolecreates implemented last GSoC.

I recommend hosting two L4S Linux servers and making successful data communications across these compute nodes (ideally, you should have access to two Linux computers in the same network for this).

Check https://github.com/KathiraveluLab/L4SBOA/blob/main/L4SkernelPatchSetUp.md for more details.

[Aditya08Vashisht]

Thank you @pradeeban sir for your response!
I highly respect your opinion on the same but as the issue i was approaching at that time (#10) was routing the front-end part of this project i which i have to implement multiple pages a well..
Hence i was just trying to confirm that part from the mentors side
i will be highly delighted if i get the feedback on that same from our respected mentors
and also look forward to work for linux server part in the future

[pradeeban]

@Aditya08Vashisht That was an issue created by another GSoC applicant, @ASHISH-JHA94 to describe his own progress.

As I noted, most of the applicants seem to focus more on the front-end aspects, whereas this is meant to be a networking/back-end project. So, time is better spent establishing your strength and comfort in Linux and Networking.

I have closed that issue.

[Aditya08Vashisht]

okay sir I'll surely be establishing my works and updations in the linux server parts show in the coming future i hope i can contribute even after 24th

[pradeeban]

Awesome! Looking forward to reviewing your proposal.
April 8 - 18:00 UTC: GSoC contributor application deadline

So you actually have time until April 8th!

[ASHISH-JHA94]

@pradeeban ,here is update from my side on same network I have successfully configured two machine one as server and one as client and successfully connected and share data between them.
As per my plan before remote deployment of servers,we should test on local or same subnet network,here I have used my college LAN network

this is server and it has successfully accepted the connection from client.

this is client and client send the connection request to the server and server accepted the connection and simple data sharing occur.

[pradeeban]

Now the next step is, configuring these nodes to have L4S enabled.

https://github.com/L4STeam/linux

As the project idea states, "Linux kernel with L4S patches can be a good point to start for the endpoints." (and this is something @kolawolecreates has already tested).

[ASHISH-JHA94]

After configuring kernel with L4S enabled on both machine using the documentaion that i have provided,then i start checking from client if i try to connect server(other machine) will it successfully connected or not.
After carefully following all the steps in my L4S kernel configuration guide, here's how to i verify that L4S is fully enabled and functioning:

Comprehensive L4S Verification Checklist

1. Kernel Verification

   uname -r

   • Confirm output shows the L4S kernel version (should contain "l4s" or similar in version string)
   • Expected example: 5.15.0-l4s+

2. Module Verification

   lsmod | grep -E "sch_dualpi2|tcp_prague"

   • Must show both modules loaded
   • Expected output:

     tcp_prague             16384  0
     sch_dualpi2            16384  0
     

3. Network Stack Verification

   sysctl net.ipv4.tcp_ecn net.ipv4.tcp_congestion_control

   • Must show:

     net.ipv4.tcp_ecn = 3
     net.ipv4.tcp_congestion_control = prague
     

4. Queue Discipline Verification

   tc qdisc show dev eno1

   • Must show dualpi2 as root qdisc
   • Expected output:

     qdisc dualpi2 root refcnt 2 limit 1000p target 5ms ce_threshold 1ms
     

5. Offload Verification

   ethtool -k eno1 | grep -E 'tso|gso|gro|lro'

   • Must show:

     tcp-segmentation-offload: off
     generic-segmentation-offload: off
     generic-receive-offload: off
     large-receive-offload: off [fixed]
     

6. Functional Test

   # On server:
   iperf3 -s
   
   # On client:
   iperf3 -c [server_ip] -p 5201 -t 20

since all verification steps pass, hence i say L4S implementation is fully active and operational.

[ASHISH-JHA94]

@kolawolecreates,is this correct or there are further commands to add on based on your previous experience.

[ASHISH-JHA94]

if the update is fine,I will add the instruction for it in setup documentation.

[ASHISH-JHA94]

@pradeeban ,
For transferring DICOM files between our L4S-configured servers, which method would you recommend among these options? Here’s how I plan to use each:

DICOM Protocol (DIMSE)

Use Case: Standard PACS-to-PACS communication (e.g., Orthanc to dcm4chee).

Pros: Built-in metadata handling, DICOM compliance.

rsync over SSH

Use Case: Bulk transfers of large DICOM datasets (e.g., nightly backups).

Pros: Resumable, checksum verification, compression.

scp

Use Case: Quick ad-hoc transfers of individual files (e.g., urgent case sharing).

Pros: Simple, encrypted, secure because it uses ssh keys,no setup needed.

DICOM over HTTP (REST API)

Use Case: Web-based integrations (e.g., upload via Orthanc REST API).

Pros: Works with web apps, scripting-friendly.

Given our L4S setup (Prague TCP + DualPI2), should we prioritize one method for latency-sensitive workflows? Or combine them based on the scenario?

[pradeeban]

we should evaluate both. @kolawolecreates did some evaluation already in the previous GSoC. Good to resume from where he left off.

[ASHISH-JHA94]

Is there any previous documentation for the work @kolawolecreates did in the last GSOC? It would make it easier to move forward and avoid repetitive work. That said, starting from scratch can also be a great learning experience.

[pradeeban]

Everything he did is in the L4SBOA repository. L4S itself is well-documented. So, you should be able to find the right documentation from their repository. I don't think we would have done a better job at documenting it. :D

Like you said, it is a learning experience too. (and you should highlight everything you have done, in getting the L4S in your proposal). This is much more important than the node/npm front-end stuff.

[ASHISH-JHA94]

.

just for Simple test purpouse,as it is easy to test.

Current Test Configuration:

Transfer Method:

• Using SCP over SSH for initial testing
• Command: scp -o IPQoS=cs6 testfile.txt user@172.21.4.251:/destination/
• Authentication: Password-based SSH (working but requires manual input)

[pradeeban]

yes, but remember about the Linux kernel patched with L4S. Most conversations on this project from the applicants (unfortunately) have steered into the front-end application and the issues with npm. Illustrating

[ASHISH-JHA94]

This confusion likely stems from the project structure, as many assume it’s primarily a React-based project due to the minimal frontend code in the repo. To address this, I believe we should update the README.md with a clear step-by-step workflow—for example:

Configure the kernel to enable L4S.
Test locally on two machines within the same subnet.

A well-documented flow like this would help contributors understand where to focus. Additionally, newcomers often miss critical context because they skip past discussions initially, only referring to them later for specific doubts. A detailed README could bridge that gap.

[pradeeban]

Good points.

The issue with the repository was, it was entirely made by GSoC 2024 contributor. So, we could only do certain things. GSoC 2025 should build on top of what we have, but with the focus on the L4S, Linux, and Network performance (rather than repeating what was already done in GSoC 2024).

Agreed about the documentation. Sadly, most contributors dislike making documentation. :D

Feel free to submit a pull request if you have time.

I think, the project description in https://github.com/uaanchorage/GSoC paints a better picture about the project idea rather than the current project repository itself. This is a common challenge of new projects. But the projects will eventually mature. Even stable projects such as CONTROL-CORE were largely built by GSoC contributors!