linux-kernel - [PATCHv2 0/5] sctp: add multistream scheduling feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 11 Sep 2010 21:12:27 -0400
From:	Yaogong Wang <ywang15@...u.edu>
To:	linux-sctp@...r.kernel.org,
	Vlad Yasevich <vladislav.yasevich@...com>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCHv2 0/5] sctp: add multistream scheduling feature

SCTP supports multistreaming. It solves the head-of-line blocking
problem of TCP and makes SCTP a proper transport for signaling.
However, this feature can be further exploited to provide QoS
scheduling among multiple streams. This is what we want to add in this
patch.

In the current implementation, multiple streams in an SCTP association
are scheduled in a first-come-first-serve (FCFS) fashion. We would
like to augment this simple algorithm with many other scheduling
algorithms and let the application choose which scheduling algorithm
they want to use. We provide a multistream scheduling framework in the
kernel so that different scheduling algorithms can be implemented as
kernel modules. We also extend the SCTP socket API to include a new
socket option for applications to choose and configure the scheduling
algorithm. This approach is inspired by the pluggable TCP congestion
control mechanism in the Linux kernel.

Note that this modification doesn't change the protocol on the wire.
It only changes the internal scheduling. Therefore, it won't cause any
interoperability problem. Further, this modification doesn't change
the congestion control algorithm of SCTP. It only changes which data
chunk should be transmitted first, under the constraints of the
congestion window. Therefore, it's safe to be deployed in the
Internet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/