From: Neil H. <nh...@tu...> - 2012-12-18 14:51:30
|
On Tue, Dec 18, 2012 at 09:45:45AM -0500, Karl Heiss wrote: > On Mon, Dec 17, 2012 at 1:48 PM, Neil Horman <nh...@tu...> wrote: > > On Mon, Dec 17, 2012 at 01:35:45PM -0500, Karl Heiss wrote: > >> Is supporting pluggable congestion control algorithms in SCTP, such as > >> those used in TCP, something that is blocked by a technical > >> limitation? Doing some quick google searches, I see that this has > >> been attempted before but I don't see any explicit mention of this in > >> the mailing list archives, neither for nor against the feature. I > >> feel like this is something that might have been discussed ad-nausea > >> before, but the lack of content I have found is surprising. Does > >> anyone have any insight into why this may, or may not, be doable? > >> > >> Regards, > >> Karl > >> > > > > I think its just not something that has gotten alot of attention. We could > > certainly do something simmilar to the infrastructure TCP has for pluggable > > congestion control in SCTP, but I don't think anyone has done much > > experimentation determining the various effects that different control > > algorithms have on SCTP throughput, given its different operational modes. > > > > Neil > > Is there anything in the RFCs or this particular implementation that > would prevent including such functionality upstream? For reference, I > found the following link which covers a particular implementation of > this: > There are stipulations in the RFC surrounding how often SACK frames must be sent (IIRC every sack_timeout or every other data chunk received), and retransmits must be gated on the reception of those sacks at expected times to work smoothly, but as long as you stay within those constraints specified by the RFC, you can implement anything you want. > http://heim.ifi.uio.no/michawe/research/projects/new-transport/implementing-sctp-pluggable-congestion-control.html > > I know that implementing such a feature would include much more > thorough testing (multiple streams, multi-homing, etc..), but would > this seem feasible? I ask this because I know that often it is more > than just the technical aspect of such implementations that are the > sticking point for getting features added upstream. > Patches always welcome :) No guarantee they'll be accepted, but were always happy to look them over and discuss them. Neil > Karl > |