linux-kernel - [PATCH 0/6] 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]

Message-ID: <AANLkTin0upoLzQUG6AmYgmAc1YlvxqMkYhaKr85oK8Mm@mail.gmail.com>
Date:	Wed, 2 Jun 2010 22:42:08 -0700
From:	Yaogong Wang <ywang15@...u.edu>
To:	linux-sctp@...r.kernel.org,
	Vlad Yasevich <vladislav.yasevich@...com>,
	Sridhar Samudrala <sri@...ibm.com>
Cc:	linux-kernel@...r.kernel.org
Subject: [PATCH 0/6] sctp: add multistream scheduling feature

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

In the current implementation, multiple streams in an SCTP association
is 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 they want to use. We
provide a general interface 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 they want. This approach is
inspired by the pluggable TCP congestion control mechanism in the
Linux kernel.

An application of this feature is as follow: suppose two users are
chatting with each other over an SCTP-based instant messenger.
Meantime, they are exchanging photos. So there are two streams in this
scenario: one for instant messages and the other for photo transfer.
In the current implementation, the user cannot specify the scheduling
of the two streams so that the instant messages may be delayed by the
bulk data transfer when the available bandwidth is limited. With our
extension, the user could choose priority queue scheduling among the
streams and put instant messages on the higher priority queue. Thus,
we can prevent the previous problems and decrease the latency
experienced by the instant messages. There may be many other possible
applications of this patch since it provides a general framework to
implement many possible scheduling algorithms.

All following patches should be applied to kernel 2.6.32.8 sequentially.

--
========================
Yaogong Wang, PhD candidate
Department of Computer Science
North Carolina State University
http://www4.ncsu.edu/~ywang15/
========================
--
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/