Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

scheduler: implement a "opportunistic retransmission" #332

Open
Tracked by #350
matttbe opened this issue Dec 21, 2022 · 0 comments
Open
Tracked by #350

scheduler: implement a "opportunistic retransmission" #332

matttbe opened this issue Dec 21, 2022 · 0 comments
Labels
enhancement sched packets scheduler

Comments

@matttbe
Copy link
Member

matttbe commented Dec 21, 2022 •
edited
Loading

The goal of the "opportunistic retransmission" is to quickly reinject packets when we notice the window has just been closed on one path, see the section 4.2 of: https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have the ability to trigger a reinjection. Currently there are only hooks to initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

Note that the packet scheduler never significantly queue more than what the cwnd of a subflow would accept: currently, the in-kernel only accepts to queue up to the MPTCP level cwnd (a few more bytes due to round-up)
@matttbe matttbe added the sched packets scheduler label Feb 1, 2023
This was referenced Feb 1, 2023
Open
Open
@matttbe matttbe moved this to Needs triage in MPTCP Upstream: Future Feb 22, 2023
This was referenced Mar 29, 2023
Closed
Closed
@daire-byrne daire-byrne mentioned this issue Sep 5, 2023
Closed
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 12, 2024
@geliangtang
mptcp: retrans optimization
0a4a27f 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 13, 2024
@geliangtang
mptcp: retrans optimization
393e627 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 13, 2024
@geliangtang
mptcp: retrans optimization
70cbef4 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 13, 2024
@geliangtang
mptcp: retrans optimization
9ab801d 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 15, 2024
@geliangtang
mptcp: retrans optimization
1b24e7d 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 16, 2024
@geliangtang
mptcp: retrans optimization
91c2d97 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 16, 2024
@geliangtang
mptcp: retrans optimization
a14e3cc 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 16, 2024
@geliangtang
mptcp: retrans optimization
768ad39 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 16, 2024
@geliangtang
mptcp: retrans optimization
ddda4dd 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 16, 2024
@geliangtang
mptcp: retrans optimization
ed0db49 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 19, 2024
@geliangtang
mptcp: retrans optimization
c6a7579 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 20, 2024
@geliangtang
mptcp: retrans optimization
202fe49 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 20, 2024
@geliangtang
mptcp: retrans optimization
42cf646 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 21, 2024
@geliangtang
mptcp: retrans optimization
e62eed5 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 21, 2024
@geliangtang
mptcp: retrans optimization
d1168ef 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 22, 2024
@geliangtang
mptcp: retrans optimization
ab428a1 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 22, 2024
@geliangtang
mptcp: retrans optimization
34a316d 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 22, 2024
@geliangtang
mptcp: retrans optimization
367bab5 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 22, 2024
@geliangtang
mptcp: retrans optimization
27316df 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Mar 23, 2024
@geliangtang
mptcp: retrans optimization
6edc045 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 10, 2024
@geliangtang
mptcp: retrans optimization
053cd02 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 10, 2024
@geliangtang
mptcp: retrans optimization
650fddb 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 11, 2024
@geliangtang
mptcp: retrans optimization
686b860 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 11, 2024
@geliangtang
mptcp: retrans optimization
84176fc 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 11, 2024
@geliangtang
mptcp: retrans optimization
b7d7253 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 12, 2024
@geliangtang
mptcp: retrans optimization
7138896 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 13, 2024
@geliangtang
mptcp: retrans optimization
8ee8f92 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 13, 2024
@geliangtang
mptcp: retrans optimization
6a8ee57 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 13, 2024
@geliangtang
mptcp: retrans optimization
5ef1b24 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 16, 2024
@geliangtang
mptcp: retrans optimization
7af56ff 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 16, 2024
@geliangtang
mptcp: retrans optimization
4127ee6 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 16, 2024
@geliangtang
mptcp: retrans optimization
47ce962 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 17, 2024
@geliangtang
mptcp: retrans optimization
cc19ef9 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 20, 2024
@geliangtang
mptcp: retrans optimization
35c91b2 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 23, 2024
@geliangtang
mptcp: retrans optimization
6ccbaaf 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 23, 2024
@geliangtang
mptcp: retrans optimization
7a25192 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 23, 2024
@geliangtang
mptcp: retrans optimization
7ccf563 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 23, 2024
@geliangtang
mptcp: retrans optimization
cf2e164 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 23, 2024
@geliangtang
mptcp: retrans optimization
29e173a 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 24, 2024
@geliangtang
mptcp: retrans optimization
78eb338 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 24, 2024
@geliangtang
mptcp: retrans optimization
71b88e2 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 24, 2024
@geliangtang
mptcp: retrans optimization
514309e 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 24, 2024
@geliangtang
mptcp: retrans optimization
4e9cad6 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 25, 2024
@geliangtang
mptcp: retrans optimization
80448e5 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 25, 2024
@geliangtang
mptcp: retrans optimization
f6aab88 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 26, 2024
@geliangtang
mptcp: retrans optimization
db145b8 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 26, 2024
@geliangtang
mptcp: retrans optimization
52ebba4 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 26, 2024
@geliangtang
mptcp: retrans optimization
caf07c4 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 27, 2024
@geliangtang
mptcp: retrans optimization
39b8d1c 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
geliangtang added a commit to geliangtang/mptcp_net-next that referenced this issue Dec 27, 2024
@geliangtang
mptcp: retrans optimization
207e1fd 
scheduler: implement a "opportunistic retransmission"

The goal of the "opportunistic retransmission" is to quickly reinject
packets when we notice the window has just been closed on one path, see
the section 4.2 of:

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final125.pdf

This is implemented in mptcp.org, see mptcp_rcv_buf_optimization().

With the current API in the Upstream kernel, a new scheduler doesn't have
the ability to trigger a reinjection. Currently there are only hooks to
initiate reinjection when the MPTCP RTO fires.

The packet scheduler should be able to get more info:

    not just when MPTCP cwnd close or the seq num has increased (max
allowed MPTCP level seq num to be sent == last ack + (...))
    but also when there is a RTO at subflow level: maybe linked to

    scheduler: react when subflow-level events pop up (ACK/RTO) multipath-tcp#343

Note that the packet scheduler never significantly queue more than what
the cwnd of a subflow would accept: currently, the in-kernel only accepts
to queue up to the MPTCP level cwnd (a few more bytes due to round-up)

Closes: multipath-tcp#332
Signed-off-by: Geliang Tang <geliang@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement sched packets scheduler
Projects
MPTCP Upstream: Future
Status: Needs triage
Milestone
No milestone
Development

No branches or pull requests
1 participant
@matttbe