[jitsi-dev] [JIRA] Closed: (JITSI-1168) Please add SCTP support


#1

Hi Emil, all,

I'm sorry I opened the feature request for SCTP without first
discussing it here,

It happens.

it has been a while since I used to be involved with development
discussions regularly, and I had forgotten the strict policy of
discussing before filing. Nevertheless, I then found myself
seriously lacking the time to enter into discussion, but I've now
finally gotten round to it.

It doesn't have to be a long discussion :). You can just do the post and
see how it goes. It has more chances of being looked at that way.

I haven't really got a lot more to add to the original feature
request other than that UDP is a real pain on our ~1.5Mb/s downlink,
~350kb/s uplink ADSL line. See below at the end of this email for the
original feature request.

so what you originially wrote was this:

Jitsi relies on UDP for audio and video communication. UDP has no
congestion control, so it can cause congestion problems for a
network's downlink. Like TCP, SCTP has congestion control, but was
designed for real-time communication. I'm planning to block UDP on
the downlink of my network, so I want Jitsi to work without needing
UDP.Besides, surely there are many other benefits to using a
transport protocol that was designed for RTC!Jitsi should be able to
use native SCTP on at least Linux (which I know has long since
supported SCTP). For platforms that don't support SCTP, Jitsi should
be able to use SCTP over UDP as a fallback.

So, while it is true that UDP has no congestion control, this means neither that SCTP would automagically add this nor that you can't have this with RTP.

In other words, if Jitsi keeps pumping N bytes per second of video and/or audio, SCTP can do absolutely nothing about it.

If on the other hand Jitsi detects congestion problems it could do several things such as: drop resolution, bitrate, framerate, etc. In this case no other protocol would be necessary and again SCTP wouldn't help in any way.

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.

Cheers,
Emil

···

On 26.11.13, 19:13, James Haigh wrote:

Thank you, James Haigh.

On 06/06/13 17:24, emcho (JIRA) wrote:

[
https://java.net/jira/browse/JITSI-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

emcho closed JITSI-1168. ------------------------

Resolution: Fixed

This would be an interesting conversation but it would have to
happen on our mailing lists.

Note that as our "Bugs and Issues" page [0] explains, we expect
reports to be submitted in the issue tracker only after they have
been discussed and confirmed as such on our dev mailing list [1].
This is really important to us and we've tried to make it clear
throughout the site. You may also like to check the following page
[2] for the rationale behind our decision.

For all these reason we may be marking this issue as Invalid. In
all cases, please report it on dev@jitsi.java.net so that we can
have a proper discussion.

[0] http://www.jitsi.org/index.php/Development/BugsAndIssues [1]
dev@jitsi.java.net [2]
http://producingoss.com/en/bug-tracker.html#bug-filtering

P.S. On a side note, we would be interested to know how you reached
the issue tracker without seeing any of the notes where we ask
users not to submit issues without discussing them with the
developers first.

Please add SCTP support -----------------------

Key: JITSI-1168 URL: https://java.net/jira/browse/JITSI-1168
Project: jitsi Issue Type: New Feature Environment: Linux
Reporter: james.haigh

Jitsi relies on UDP for audio and video communication. UDP has no
congestion control, so it can cause congestion problems for a
network's downlink. Like TCP, SCTP has congestion control, but
was designed for real-time communication. I'm planning to block
UDP on the downlink of my network, so I want Jitsi to work
without needing UDP. Besides, surely there are many other
benefits to using a transport protocol that was _designed_ for
RTC! Jitsi should be able to use native SCTP on _at least_ Linux
(which I know has long since supported SCTP). For platforms that
don't support SCTP, Jitsi should be able to use [SCTP over
UDP>https://ietf.org/proceedings/48/I-D/sigtran-sctptunnel-00.txt]
as a fallback.

_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#2


It doesn't have to be a long discussion :). You can just do the post and
see how it goes. It has more chances of being looked at that way.

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,
so this is the beginning of me testing that newer versions of Jitsi have
solved problems I wasn't happy with, and potentially getting back into
longer discussions relating to development.

I haven't really got a lot more to add to the original feature
request other than that UDP is a real pain on our ~1.5Mb/s downlink,
~350kb/s uplink ADSL line. See below at the end of this email for the
original feature request.

so what you originially wrote was this:

Jitsi relies on UDP for audio and video communication. UDP has no
congestion control, so it can cause congestion problems for a
network's downlink. Like TCP, SCTP has congestion control, but was
designed for real-time communication. I'm planning to block UDP on
the downlink of my network, so I want Jitsi to work without needing
UDP.Besides, surely there are many other benefits to using a
transport protocol that was designed for RTC!Jitsi should be able to
use native SCTP on at least Linux (which I know has long since
supported SCTP). For platforms that don't support SCTP, Jitsi should
be able to use SCTP over UDP as a fallback.

So, while it is true that UDP has no congestion control, this means
neither that SCTP would automagically add this nor that you can't have
this with RTP.

In other words, if Jitsi keeps pumping N bytes per second of video
and/or audio, SCTP can do absolutely nothing about it.

As I understand, the congestion control functionality of TCP and SCTP
allows any device along the way to shout upstream to “slow down”. This
is why UDP is a problem at the ADSL bottleneck, 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. 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.

This happens on slow connections anyway, only it's at bottlenecks rather
than at the source, so even though it is a very crude implementation, it
is actually less crude than it currently stands, and would allow future
integration with more advanced bitrate adaptation.

If on the other hand Jitsi detects congestion problems it could do
several things such as: drop resolution, bitrate, framerate, etc. In
this case no other protocol would be necessary and again SCTP wouldn't
help in any way.

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. Nevertheless, it is a separate issue to SCTP
support. Bitrate adaptation is how to deal with congestion from the
point-of-view of the callers.

SCTP on the other hand, gives me more options on how I can deal with
congestion from the point-of-view of /routers/. 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> 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! Yeah, doesn't sound so exciting for those of you on fibre or 4G. :stuck_out_tongue:

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, but although
bitrate adaptation does also interest me, it's not the same thing as
SCTP support. 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. And if
neither the WiFi network or the mobile network were quite fast enough to
support decent video streaming, the SCTP multihoming could form the link
aggregation needed to sustain a much better quality connection.

Please don't clump this together with advanced bitrate adaptation; I
hope you won't wait 3–6 months before doing anything. It is surely not
as hard as you make it out to be if you forget about bitrate adaptation
for the time being. Just dropping packets at the source instead of at
the bottleneck is already an improvement.

Thank you,
James Haigh.

···

On 26/11/13 19:40, Emil Ivov wrote:


#3

Hey James,


It doesn't have to be a long discussion :). You can just do the post and
see how it goes. It has more chances of being looked at that way.

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,

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).

So, while it is true that UDP has no congestion control, this means
neither that SCTP would automagically add this nor that you can't have
this with RTP.

In other words, if Jitsi keeps pumping N bytes per second of video
and/or audio, SCTP can do absolutely nothing about it.

As I understand, the congestion control functionality of TCP and SCTP
allows any device along the way to shout upstream to “slow down”.

No. This is not the case. Both SCTP and TCP are end-to-end protocols. Sessions are negotiated and torn down by the two devices establishing a particular connection.

The way congestion control works in both SCTP and TCP is pretty much a trial and error story, where both parties regulate their stream based on the losses they've suffered.

This also how RTP congestion control works.

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 why UDP is a problem at the ADSL bottleneck,

It is worth mentioning that most of the time SCTP won't go through home gateways that are only used to dealing with UDP and TCP. SCTP over UDP would. The point is that UDP in itself is not a problem. The lack of congestion control is.

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.

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.

This happens on slow connections anyway, only it's at bottlenecks rather
than at the source, so even though it is a very crude implementation, it
is actually less crude than it currently stands, and would allow future
integration with more advanced bitrate adaptation.

If on the other hand Jitsi detects congestion problems it could do
several things such as: drop resolution, bitrate, framerate, etc. In
this case no other protocol would be necessary and again SCTP wouldn't
help in any way.

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 :).

Nevertheless, it is a separate issue to SCTP
support. Bitrate adaptation is how to deal with congestion from the
point-of-view of the callers.

SCTP on the other hand, gives me more options on how I can deal with
congestion from the point-of-view of /routers/.

Again, that's QoS. Routers play absolutely no role in SCTP congestion control.

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> 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.

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. :stuck_out_tongue:

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.

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.

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.

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.

And if
neither the WiFi network or the mobile network were quite fast enough to
support decent video streaming, the SCTP multihoming could form the link
aggregation needed to sustain a much better quality connection.

Already answered.

Please don't clump this together with advanced bitrate adaptation; I
hope you won't wait 3–6 months before doing anything. It is surely not
as hard as you make it out to be

Maybe ... I'd be very happy if someone was to prove me wrong.

if you forget about bitrate adaptation
for the time being.

Just dropping packets at the source instead of at
the bottleneck is already an improvement.

No, it's not. It's exactly the same.

Emil

···

On 28.11.13, 04:18, James Haigh wrote:

On 26/11/13 19:40, Emil Ivov wrote:

--
https://jitsi.org


#4

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. :slight_smile: 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> 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! :smiley:
    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! :smiley:

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. :stuck_out_tongue:

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. :frowning:

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! :wink:

James.

···

On 28/11/13 10:55, Emil Ivov wrote:


#5

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.

What you are describing here is quite different from the suggestion you
originally made and the one I was describing as a research subject, namely:
"use of sctp would automatically let your video stream over your two
uplinks".

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.

I think you realise that though, so I am not sure why you are mentioning
this at all.

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.

Great then, feel free to resolve it the way it makes sense to you.

Are you sure this isn't a case of Swiss army knife syndrome

:slight_smile: ... next time you read through an SCTP overview you might want to go
beyond the "supports multihoming" check and into the section that actually
explains exactly what is meant by that and how it works. Then put that into
the context of SIP/XMPP negotiation of RTP sessions in the context of ICE
and NATs. While you are ate it, You may also want to have a look at other
network layer technologies for this: Mobile IP, FMIPv6, PMIP, etc.

You may then want to reconsider tye above statement.

--sent from my mobile

···

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. :slight_smile: 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! :smiley:
    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! :smiley:

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. :stuck_out_tongue:

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. :frowning:

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! :wink:

James.