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: <AANLkTi=3me5AsWLVpy7Xku_Qr2ajxJzHULnhWgSz14k=@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ