Bit torrent establishes multiple connections over all available interfaces.
That's a very different thing from automatically splitting the same session
so that it would benefit from band aggregation. SCTP is not going to
resolve this for you.
Great then, feel free to resolve it the way it makes sense to you.
You may then want to reconsider tye above statement.
···
On 28/11/13 10:55, Emil Ivov wrote:
…
Perhaps not, but in actual fact I haven't used Jitsi for a while
unfortunately because it didn't perform well for me when I last tried,
Well I should say ‘well *enough* for me’ actually, because Jitsi is
actually pretty impressive overall. 
It works well across the LAN for
example.
I understand this and I would love for us to have congestion control. The
thing is that we currently don't and we have a To Do list which is long
enough to guarantee that it won't be something we can look at in the very
near term. (I am mainly speaking for BlueJimp here but I haven't had
indications to the contrary from other community members. If I am wrong,
please let yourselves known and we can start working on this immediately).
If this discussion concludes with a good solution, I may ask you (off-list)
about being a BlueJimp customer for a while. That probably won't help with
time though, unless you were pondering employing someone and you didn't
quite have enough revenue to do so, but, I don't know, it should at least
help you in some way.
…
As I understand, the congestion control functionality of TCP and SCTP
allows any device along the way to shout upstream to “slow down”.
…
Now, what you probably mean here (thanks Chenzo for the point) is use of
Explicit Congestion Notification (ECN). If so, then that is not an SCTP
exclusivity. It's something that routers perform at the IP layer. It is
also not so widely deployed and chances are that you don't have it on your
network.
This is exactly what I mean. ECN. I couldn't remember it. (Really I should
have looked it up before sending my last email.) Yes, apparently it can be
done at the IP layer, but also in SCTP and TCP. I may or may not have it on
my network currently, but if not I can change that. I use OpenWrt so I can
pretty much customise anything I want. Nevertheless, it isn't your problem.
If you can support ECN in the future, I'll find a way of using it, and
should definitely have that sorted in the timescales you are talking about.
Anyway, now that you point out that ECN can work at the IP level
(previously I thought it was a feature of SCTP and TCP only), you should be
able to support ECN independently of SCTP. That doesn't mean to say that
SCTP isn't useful though; I find it very hard to believe that a transport
protocol designed to be fit for telecommunications doesn't have any
advantages over the very old UDP protocol.
…
It is worth mentioning that most of the time SCTP won't go through home
gateways that are only used to dealing with TCP and UDP. SCTP over UDP
would. The point is that UDP in itself is not a problem. The lack of
congestion control is.
SCTP passes through my home gateway absolutely fine. And although I use
OpenWrt, I have actually still got a ‘typical’ router at the gateway. There
is a non-OpenWrt Belkin router that, these days, does nothing but act as an
ADSL modem (because its firmware is so rubbish) for an Ethernet-only router
flashed with OpenWrt. The Belkin firmware doesn't have an option of
actually *being* a modem, so at the moment I actually have a situation
where I have two NAT gateways chained together. (Unfortunately, the Belkin
doesn't have an OpenWrt port for it, so ideally I should replace these two
routers with a single ADSL router that is OpenWrt-supported, and sell the
Belkin.) I would have been surprised if OpenWrt couldn't handle SCTP, it
passes through just fine, but since it passes through both gateways it also
demonstrates that the rubbish Belkin router is also capable of letting SCTP
through. I think it is actually not true that SCTP won't pass through most
home gateways.
It is though true for port forwarding, manual at least; the Belkin has
no options other than TCP or UDP, whereas OpenWrt can port forward any
protocol, even ones it does not know about by using a custom option. I
wouldn't be surprised if the firewalls of many routers would actually only
block relevant ICMP/IGMP/TCP/UDP traffic, and overlook all other protocols.
This would be the contrary to SCTP not going through – SCTP and other
lesser known protocols may actually be security holes in some poorly
designed router firmwares because they are overlooked.
Nevertheless, you have raised a couple of interesting questions for me.
Port forwarding is required for direct P2P communication if both peers are
behind NATs, so I wonder if I have reached the limitations of the Belkin.
I'll have to test whether pointing the Belkin's DMZ feature at the OpenWrt
gateway would forward everything (not just TCP/UDP), and allow the OpenWrt
router to port forward SCTP connections. Furthermore, to be useful to
people without OpenWrt, I wonder if it is the case that although a typical
home router doesn't expose SCTP or a custom field in the port forwarding
section of its webIF, it is still able to forward an SCTP port via UPnP.
Maybe – I'll have to experiment. Although seeing as I have had trouble with
the Belkin's UPnP in the past anyway, along with many of its other
features, it may not the best thing to experiment with, but if I actually
*do* get it working, it will surely be a good sign that it will work on
many other routers! But yes, there may be a few issues regarding ICE if it
turns out that most routers cannot set up an SCTP port forward via UPnP.
although I can drop
uplink packets of lower priority connections when there is congestion,
dropping downlink packets at this end is pointless because they have
already passed the bottleneck. So all I need is to be able to slow down
the downlink of a connection.
What you are describing sounds a lot more like QoS and that's neither an
SCTP, nor an RTP problem.
Yes, my mistake. It's an ECN problem, which can be part of SCTP, but yes, I
was talking about using ECN to provide QoS.
Nothing fancy; the implementation of SCTP
would include, at the very minimum, the causing of Jitsi to drop some of
its own outgoing packets when it has been told to slow down its connection.
That's pretty much what it would do with RTP congestion control too. Only
it would do it in a way that still gets you a viewable stream.
By ‘viewable’, do you mean viewable to the router, or a less broken video
link?
…
Yes, I understand this. I'm sure I've had discussions about this in the
past. You really need to put this higher on your list now that you have
long since left the alpha/beta stage when there were so many other
things you had to do.
I can assure you that today there are even more :).
D-: Yes I can imagine, as always, but surely bitrate adaptation has got to
be getting up there these days, along with Android support which btw.,
congratulations, is actually just about functional! For audio and receiving
video at least; haven't managed sending a video stream yet though.
…
SCTP would not only help
me with prioritisation, but it should also allow me to increase the
maximum throughput available to SCTP connections by using the
multihoming capability of SCTP in combination with a multi-WAN
<http://wiki.openwrt.org/doc/uci/multiwan><http://wiki.openwrt.org/doc/uci/multiwan>setup
in OpenWrt to perform
link aggregation. I can get up to 3.6Mb/s 3G where I live, but it has
higher latency than the copper ADSL line. Reluctant to trade lower
latency for higher throughput, I'm thinking about trying a multi-WAN
setup. Multihoming SCTP connections could potentially utilise over
5Mb/s!
Eer ... OK. Now this is becoming science fiction. SCTP's multihoming
capabilities are mostly meant for transparent fail-over and, last I
checked, bandwidth aggregation was still pretty much a research subject.
Hey! I'm glad you think so! I had a go at setting up this multi-WAN
configuration on Thursday, and WOW! I did it! And I actually measured an
average of 5.2Mb/s on a bittorrent download, and with peaks of 5.8Mb/s! Not
only that, I could just disconnect either of the two connections ad-hoc and
the download would continue at the speed of the remaining connection. It is
also working very well in general for protocols that can't aggregate the
channel throughputs, because, in anycase, everyone's data usage is being
load-balanced between the two WANs. It does feel a bit science fiction that
I managed to just over triple our throughput capacity to above that
available in our area! 
And the slightly more sluggish web browsing that I saw on 3G isn't
noticeable on this setup, because presumably the connections opened for
loading various parts of a single web page are being split between the two
channels, and so may actually be slightly more responsive. For me, this
setup is no longer an experiment – it's definitely a keeper. And gosh I
wish that I'd gotten round to trying this sooner. Only trouble is that
whenever someone wants the speed boost, someone has to leave a smartphone
upstairs USB-tethered to an(other) OpenWrt router, in a window where it
gets good enough reception. I could use an old dongle I have, but then I
would have to pay for another contract.
Anyway, it proves the point. Not so restricted to research, and
actually really really useful! I don't dispute the sci-fi bit though!
I agree what you are describing sounds real nice, but implementing SCTP in
Jitsi isn't going to give it to you.
Yeah, doesn't sound so exciting for those of you on fibre or 4G. 
It actually does. Don't get me wrong. I agree congestion control is
important and I would very much like it if we had it and if your experience
was to be improved. What I am trying to explain is that it's not as simple
as "activating SCTP support" and it's not the only important thing we have
on our plate.
Yes, I understand. Initially, I thought the hard bits were implemented
either by the OS, or in the case of Java, Java 7, but these things always
seem to turn out to be more complicated than they first appear. 
Implementing congestion control in Jitsi has been a long standing
subject for us but we haven't got around to it. It's also a
complicated matter. It's currently being looked at by the RMCAT
working group at the IETF. We would possibly be interested in the
output of that WG.
Feel free to open a ticket for congestion control but don't expect
much in the following three to six months.
I'm sure there's already a ticket lying around somewhere,
There isn't.
Oh yeah.
Well, I've had long discussions about it in the past, so I'll dig them
out and read them before filing a ticket, because I remember having some
useful ideas which I'd want to distil for the ticket. Is it okay if I file
congestion detection and bitrate adaptation separately, as explained below?
but although
bitrate adaptation does also interest me, it's not the same thing as
SCTP support.
Indeed it's not. Congestion control for RTP is *much* more likely to
improve your situation than SCTP support.
Having gone into this more, it looks like there are three separate features:
- Congestion detection – ECN support and packet loss detection. SCTP may
be useful for this. The implementation should estimate the allowable
bitrate, and at the very minimum, evenly drop packets to meet this.
- Bitrate adaptation – Framerate, resolution, compression quality etc.
can be reduced to meet the allowable bitrate estimated by the congestion
detection.
- SCTP multihoming – Allowing for link aggregation, seamless handover,
and fault-tolerance.
The main reason I asked for SCTP support was for the congestion detection
and bare-minimum self-limiting. Yes, bitrate adaptation is actually more
useful to me, but it requires congestion detection as a foundation anyway,
and to me, detection is conceptually much simpler than adaptation, so I
thought it would be less to ask for to start off with.
When I filed the original feature request, I thought it was too much to
ask for SCTP multihoming support, but having now achieved the OpenWrt
multi-WAN setup, this may actually be the most useful of the three features.
Even though SCTP would perhaps help lay the foundations
for the congestion detection required for the bitrate adaptation, it
also opens other possibilities. For example, in the future, it may be
possible to allow mobile Jitsi to seamlessly handover between WiFi and
cellular networks by utilising the multihoming capabilities.
It's much more complicated than this. Transparent handover with Jitsi is
probably best handled by the application-layer protocols.
You do seem to like your application-layer protocols! It doesn't make sense
to me that this is not best handled at the transport layer since, well,
this is a transport issue. Are you sure this isn't a case of Swiss army
knife syndrome?
…
Just dropping packets at the source instead of at
the bottleneck is already an improvement.
No, it's not. It's exactly the same.
Well, it can't be *exactly* the same. There is a subtle difference.
Consider a connection not fast enough for the full quality of two VoIP
video calls. When the calls are established packets will be dropped at both
ends of the ADSL link. At my end I can drop packets evenly between the two
calls. However, at the ISP end, throughput may be flapping about
erratically between the two calls and, assuming that inconsistent packet
loss has a greater impact on quality, this will degrade the received
quality for both callers on the LAN side. If I can tell both calls to slow
down to the half-way point, the packets dropped at source can be dropped
perfectly evenly, and this should result in a much more stable and
consistent experience.
It also lays foundations for more advanced bitrate adaptation rather
than just dropping packets, because of course, the bitrate adaptation has
to be done at source so the problem is at least in the right place. Right
now the effective (received) bitrate is being ‘adapted’ (shaped by
packet-loss) somewhere out on the Internet, so you can't do anything with
it there! 
James.
It works well across the LAN for
