Dirk Kutscher

Personal web page

Archive for the ‘teach’ Category

Back to Humboldt — or How to Organize your Teaching in covid-19 Times

without comments

Many university-level teachers have switched or will have to switch to online teaching and coaching. My university switched relatively seamlessly a few weeks ago already, and I have a received quite a few requests for advice, so let me share some thoughts here.

The TL;DR summary:

  • keep calm and carry on;
  • understand your objectives and teaching methodology;
  • balance technology and didactics concerns;
  • avoid tool chaos;
  • use existing infrastructure;
  • understand scalability requirements and infrastructure constraints;
  • record everything;
  • leverage new possibilities;
  • and if you have pick one online teaching tool, use BigBlueButton (see below).

First of all, it's interesting to see how different universities in different countries approach the covid-19 crisis. Some have switched immediately to online teaching (or just extended their already existing online courses). Others announced extended Easter breaks, and there are even discussions of just canceling the summer term.

While the prospect of Corona holidays (or just more time for other work) may sounds attractive, I would strongly advise against it for two reasons:

  1. Extended breaks, suspended periods of teaching etc., will most likely result in more stress for everybody (professors, students, admin staff) later. In a situation with many uncertainties that may well hurt us more in the end.
  2. The lock-down (in whatever regional variant) is necessary, but it's obvious that you cannot lock down everything (hospitals, food production etc.). Every social and business activity that is locked down will hurt society in some way. There are some activities that cannot continue right now and absolutely have to be suspended to avoid community transmission, which is causing enough problems (small shops, artists but also larger scale factories). Luckily, there are some professions that can be re-organized and continue in some way -- university-level teaching is one of those. These activities should continue just to minimize societal damage.

In my university, the term started on March 1st. Luckily, the executive leadership had been quite up-to-speed regarding covid-19-related measures in the weeks before in terms of communication, sanitation, travel advice etc. When the federal state of Lower Saxony in Germany announced the suspension of presence-based teaching in universities in schools on March 13th, it did not come unexpected, and we continued most courses online in the next weeks.

Obviously, not everything went perfectly, and there were a few lessons learned that I will summarize in the following. I do research and teaching in Networked Systems (Computer Science), so there is a certain technology bias here.

Avoid Tool Chaos -- Use Existing Infrastructure as Much as Possible

Most universities are using some kind of learning management or e-learning system such as Moodle. They are never perfect of course, but it is really a good idea to use them as much as possible, because:

  • your students are already enrolled and typically know the system well;
  • Moodle and similar systems provide a ton of collaboration features that you may have ignored so far but that are really useful such as Wikis, forums, etc. They may not always be super-fancy as some individual externally-hosted services -- but think about your priorities in crisis timesā€¦
  • Your learning management and e-learning systems are production tools that contribute to your university's core business, so there is a good probability that they are actually well-provisioned and well maintained -- good in times of fast-growing demand.

Of course everyone has their favorite Wiki, shared editing, online collaboration tool etc., but just going for these incurs cost on two sides:

  • You have to select, assess, set-up and configure them. When things break because of exploding demand, you have to re-iterate etc.
  • The combinatorial explosion for students that have to deal with all the different preferred tools is significant.

Understand Your Objectives and Teaching Methodology

When presence-based teaching is suspended, many people would probably think: "OK, I have to do Zoom lectures now".

First of all, translating all presence-based activities directly to online lectures will most likely be extremely stressful for both you and your students. You would not imagine the fatigue that sets in after a full day of different online courses. So, it's not unreasonable to scale down both the density of individual lectures as well as their cadence.

Moreover, not everything has to be done in synchronous online meetings. Luckily, there are many ways to share knowledge, engage in discussions that are used productively in non-covid-19 times such as shared editing, Wiki, forums (see above).

Finding a good balance between synchronous and asynchronous teaching/collaboration can also really transform your courses from traditional teaching & examination to something more interesting.

Also, reach out to the didactics experts in your organization (or elsewhere). They may actually have good tips for unconventional methods that were never quite practical but might just be useful now.

In that context, most people would probably agree that good education ("Bildung" in german) is more than programming skills into brains, so the crisis could be a good opportunity to double down on (r)evolving education to the Humboldtian model of higher education.

Specifically, I am referring to promoting self-determination and responsibility, encouraging self-motivated learning, and combining research and teaching.

So when thinking about methodology and tools, do not only think about the tools that you use -- also think about what you offer to enable students study, discuss, research without you. Luckily, most students don't need to be taught with respect to good online collaboration tools, but it may still be useful to provide a space on a reliable platform, at least for kickstarting things.

With respect to tools, personally, I have converged to:

  • asynchronous collaboration tools (forum, Wiki, tests) in Moodle;
  • file sharing, collaborative software development with gitlab;
  • online teaching with BigBlueButton (see below);
  • online discussion (smaller groups, chat rooms for students) with Jitsi Meet (see below);

I have been using many of those before anyway, so no big change.

As a meta-remark, I would also recommend to manage everyone's expectations (especially your own ones): crisis means change for everyone, lots of improvisation, hopefully lots of volunteer efforts. There is really no need to expects (and demand) perfection. While it's good to carry on and make sure students get their education and degrees, nobody will be angry if there is slow-start, some slack in-between and some prioritization of fewer topics -- maybe quite the opposite.

Online Teaching and Tools

Having sorted out asynchronous vs. synchronous collaboration above, there is still a lot to be said about online teaching tools. Again, it's quite important to understand your objectives -- and what the individual tools are actually intended for. Also, when deciding on a particular tools or platform, it does not hurt to understand some technical basics, such as how Internet multimedia works, what scalability means, how infrastructure constraints may affect your experience etc.

It's very natural: when we have worked with some online communication/collaboration tool, and it worked OK-ish, we tend to use it again, sometimes also for unintended purposes. However, it's important to understand two things:

  1. Online teaching can mean different things (making video available vs. interactive online classrooms), and although you can stretch things sometimes, there is not one tool that fits all purposes.
  2. Just the fact that a tools worked once for you, and the user experience was not completely horrible, does not imply that it will work well in your lecture.

Different Forms of Online Teaching

This might be self-explanatory to most, but let me just quickly explain the basics:

  • Lecture Streaming/Broadcasting (on YouTube, Twitch and similar platforms) is great for distributing recorded or live content to audiences. Although there are chat-based feedback mechanisms, it's not the same as virtual classrooms with interactive discussion, collaborative editing etc. Don't get me wrong, I have used YouTube for live lectures myself and it's OK if you can accept the constraints. I would use it for public, pre-recorded content mostly.
  • General-purpose online multimedia communication (with Skype, Jitsi Meet, Google Hangouts, WebEx, Zoom etc.) is great to discuss in your team, family etc., and sometimes they can also scale to larger conference calls, but they are not primarily intended for online teaching. For example, these tools would often lack collaborative editing, integrated document sharing, integration with learning management and e-learning systems etc. Of courses, some of them are also quite feature-rich and certainly usable (I have done lectures with tools like that without problems), but it's better to treat them as a fallback -- for example in crisis times, when you need a fast solution.
  • Online Teaching tools (for example BigBlueButton) are specialized multimedia conferencing tools that provide extra functionality to ensure a good teaching and learning experience. For example, they make sure that presentation material sharing works really well (and is not just window sharing in a video stream), they use reasonable resolution and bandwidth settings that balance quality and resource efficiency, somebody has thought about UX design for teachers' view, they make it easy to share session recordings, and they integrate with your LMS.

The point here is not that one of these is better than the others -- these are really just different categories for different purposes. If you can, pick the right one for your needs.

Technical Constraints

Believe it or not, thanks to relentless research and engineering efforts by the networking community, namely the IETF and IRTF, (interactive) multimedia real-time communication is technically a solved problem. Still, sometimes things get screwed up badly -- why?

With most hosted online communication tools, there is really no point in extrapolating one's one-time experience to general applicability in a class room scenario. Even if tool A worked well in your class today, it does not have to mean it will well for your colleague tomorrow. There are different factors that affect, for example scalability and usability, especially in crisis times.

For example, when talking about scalability, there are two dimensions:

  1. How many participants can you have in one session? Obviously, this also depends on what you do, e.g., is there one video sender or 100? But independent of that, some tools may have design characteristics (video formats and encoding options, protocols, scalability of the server software) that make them support larger crowds better or worse than others.
  2. How many conferences can you have the at the time? Assuming you are a university, this would be an interesting question. For hosted systems, this fundamentally depends on the available (or allocated) resources, i.e., servers at your provider.

In other words, there can be systems that are great, a pleasure to use from a software design perspective, but in order to make a credible statement on applicability to your online teaching, you need to consider:

  • Who is hosting the system?
  • How does performance isolation work?
  • How oversubscribed is the service (now and at peak times)?
  • What is the latency between you (your participants) and the server(s), i.e., where are they hosted?

Some conference systems work with static resource allocation, for example one virtual machine per personalized conference server. This can work well, depending on how many VMs are allocated to one physical server. Others may use modern cloud-native auto-scaling. In general, great -- but it still depends on how generous you are with respect to resource allocation.

The point I am trying to make is that it is often not very helpful to recommend your popular tool if you cannot say anything about the deployment parameters and the particular scaling approach.

Third-party Hosting vs. Self-Hosting

With all these uncertainties with externally hosted services one might ask: isn't it better to run a self-hosted conferencing server (farm), for example a licensed commercial system or an Open-Source system?

Well, this depends a lot on your infrastructure: Assuming you are using interactive online teaching with at least one video stream at a time, with todays technology you would need about 1 MBit/s per participant, i.e., 100 MBit/s for a class of hundred (on average -- can easily be double or more, depending on video quality). A university has many simultaneous lectures, so you might be reaching 1GBits/s with 10 simultaneous lectures already. That's not necessarily too much -- it depends on your institutions internal network and access to the Internet.

Video servers are also relatively resource-hungry. Nothing that cannot be handled by a few powerful servers, but you would have to set them up with a load balancer, maintain them etc.

This can all be done, and your typical sysadmins should be able to do that -- but it's probably not the right choice when your provost tells you that everybody has to switch to online teaching tomorrow.

My Recommendations

I am using a mix of asynchronous and different synchronous collaboration tools, i.e., as mentioned above:

  • Moodle-based management and collaboration (mailing lists, basic Wiki, forum, tests etc.)
  • gitlab (git repository plus Wiki mostly)
  • Self-hosted Jitsi Meet for online meetings
  • University-hosted BigBlueButton for online teaching

In the spirit of full transparency, I am also using WebEx as a fallback (kindly sponsored by Cisco) just to have some redundancy.

I am considering to use some form of instant messaging system (probably Jabber) to create a more inclusive, connected community for courses, but have not found the time yet to set this up. I used Slack before for university projects, but I don't want to make it a rule for all courses.

Jitsi Meet

Jitsi Meet is an Open Source video conferencing tool that you can use using Jitsi's server or host on your own infrastructure. It's using WebRTC (i.e., media streaming in your browser). Communication between your browser and the server is encrypted. The server is not mixing video (like on some systems) but is using selective forwarding (i.e., switching the main video stream depending on configuration and on who is currently talking).

It's a great tool that is sometimes underestimated because you don't see the different options when you just use the public service. For example Jitsi can do recording, youTube live streaming, collaborative editing (through Etherpad). There are also ways to run it with load-balancers for better scalability and availability, and you can even network the video bridges for better experience in global, large-scale conferences.

Load of our Jitsi VM with three parallel conferences (lectures, meetings)

There is still work to do with respect to video codecs (at least the transmission rates can be quite high sometimes), the way that recording and streaming is implemented (through a pseudo client that grabs video from a Chrome client) and usability of the server software (nothing crazy).

My recommendations for running your own Jitsi Meet server:

  • Use the docker installation option that runs the different server components in docker components and makes the initial setup really easy (including automatic Let's Encrypt certificate installation);
  • Encourage your users to use the desktop client application (instead of running it in a browser). The desktop client contains the same WebRTC code in a package. It works a bit better (performance- and reliability-wise) compared to using your average Chrome or Firefox -- I suspect because of potential feature interaction with Addons (and I use quite many).
  • Use the options for muting participants on joining and enforce certain rules for larger meetings (i.e., mute everybody except the main presenter, turn off video unless needed etc.)
  • Jitsi will happily use the best video quality that your camera can produce. Often, that is not needed -- you can configure lesser quality (which can reduce server/network load significantly).
  • The bottleneck in a Jitsi-Server is typically the network interface, so try to run in on server with a 10Gbit/s-interface for better results.

In my group, we set up our own server in the week before presence-based teaching got suspended, and it has proven to be super-valuable, especially when many of the centralized server-based systems failed on day one. Some of my colleagues are using it regularly for their courses.


BigBlueButton is a web conferencing system designed for online teaching and learning:

  • You can maintain several rooms (say one per class, each of which with its own configuration, recordings etc.). Every room has a unique URI -- that's all students have to know.
  • the UI is designed to enable tracking video, shared material, participants roster, chat windows;
  • presenting slides etc. is not done via screen/application sharing but though a dedicated distribution channel: you can upload PDFs and other formats to the server that then distributed this to the clients -- works much better than screen sharing in a video stream;
  • live multi-user whiteboards;
  • user polling;
  • recordings and replay on the platform; and
  • learning management system integration.

I am really convinced by the overall look and feel of the system and its performance and scalability. So far, I have used in lectures with up to 60 participants (on a spare, not high-end server) without any problems. The resource requirements seem comparatively lower compared to Jitsi Meet, probably also because of a more careful configuration of default video sending rates.

BigBlueButton Management Console (in Firefox)

From a security perspective, BigBlueButton uses encryption for all communication between your browser and the server (but the server still needs to have access, like the Jitsi Meet server).

My recommendation for running your own BigBlueButton server:

  • The client software runs well in a number of browser (tested Safari, Chrome, Firefox) so far. If you want to use WebRTC desktop/application window sharing, make sure you use it with Firefox or Chrome.
  • For university-scale deployments there is a load balancer for BigBlueButton that would allow to add more servers as you grow.

In summary, I am convinced that BigBlueButton addresses most if not all online teaching requirements. If you find a way to run or it (or have it hosted), you should use it.


Many of us had experimented with recording lectures before (for example, for flipped classroom setups). Now, with the general shift to online lectures, recording essentially becomes a "by-product", i.e., you can just turn it on (if your system supports it).

In the current crisis period, recording is actually not only nice-to-have -- I would even say that it's a crucial feature:

  • Having the possibility to provide access to recorded lectures can remove a lot of pressure in times of distress. There is a lot to process for each of us and just knowing that there will be recordings creates additional assurance.
  • Online teaching sessions are peak-utilization periods. Having videos for asynchronous consumption can help distributing the load because not everybody has to join the simultaneous live streaming.
  • Depending on the region your students live in, access networks may not be perfect, especially not if you have to share a low-bandwidth link with another student who is supposed to follow online lectures.
  • In times of lock-downs and travel restrictions, some of your students may actually be out of the country without a chance to return any time soon. They may not even be in the same timezoneā€¦
  • Although you would expect that everyone is currently practicing home-sheltering and should have lots of time on their hands, don't forget that crisis times can actually mean real crisis for
    individual people: they may have to take care of family members or
    themselves, queue at supermarkets, doctors' offices etc. -- so just because you are sitting at in your home office, does not have to imply that everybody is.

In summary, consider recording everything (with participant consent) and make it available whenever possible.

To Zoom or not to Zoom?

Zoom has been getting a lot of bad press recently and I'm getting many questions from colleagues and friends about it.

First of all, Zoom is a modern video conferencing service with excellent scaling properties, so performance is typically good, and it's also very easy to use.

Should you use it?


While some of the recent online articles are hyperbole and based on an incorrect understanding of how these systems typically work, there are, in my opinion, some strong arguments to stay away from Zoom:

  • Zoom is presenting itself as a (paid) conferencing service. However it has turned out that they also work with quite a few infamous tracking systems, i.e., they share data about you (and everyone who is using it) with the online tracking industry. Many websites do that because it's their main business model, and many users haven't been aware before GDPR at least forced them obtain your consent. It's not obvious why a commercial conferencing service has to do that, though.
  • For some websites and services, we have gotten used to ubiquitous tracking and we may either accept or not, or find ways to contain it (difficult). Personally, we may even be OK with tracking. However, it's a different thing for online teaching where you have a captive audience. By using a tracking-encumbered system in your lecture, you are essentially forcing your students to use it, too -- and to become a subject of tracking and surveillance themselves.
  • The Zoom client runs in a web browser (where expert users may be able to contain the tracking to some extent), however Zoom is trying to force users to install the standalone application.
  • Unfortunately, Zoom has demonstrated time-over-time that they do not understand basic system security, for example: webcam hack, malware installation trick on MacOS, use of single AES-128 key in ECB mode.

Bruce Schneier has summarized the most critical issues. Zoom is apparently another company that adopted the "grow fast, apologize later" approach and is now trying surf on the covid-19 wave to accelerate their growth at whatever cost.

These models used to be standard in the web and advertisement industry. Time is changing though, and as more people understand the problems of intransparent, uncontrolled surveillance, aggregation and unlimited storage, these business ethics will become increasingly unacceptable. In a few years we will look at it bewildered -- like we look at Weinstein-type misogyny in #MeToo times.

I am hoping that Zoom as a company gets the message, but I am not confident to be honest.

Luckily, for online teaching, we don't have to care because there are better alternatives anyway.

So, make wise choices.


  • 2020-04-04: Fixed formatting and other nits; added Zoom AES-128-ECB vulnerability and links to Citizen Lab's and Bruce Schneier's blog postings about it.

Written by dkutscher

April 2nd, 2020 at 11:01 pm