# data[].attributes.body
Feedback for this module will be both synchronous and asynchronous.

During lab sessions where students are implementing scheduling and congestion control algorithms, they will receive individual and verbal feedback on their design, implementation and analysis of latency/jitter etc. This ensures technical competency.

Following the ungraded Vevox polls to check the students’ knowledge of various topics such as QUIC protocol evaluation, I will provide a "Common Pitfalls" summary to the whole class to address shared misconceptions about protocol overhead.

Following the graded in-class MCQs, the students will receive automatic and detailed feedback for each incorrect choice, explaining why that option was not the right one.

Students will receive formal feedback three times across the second half of the semester:

1. Week 9 and 11 (Formative): Individual and verbal feedback on lab work.

2. Week 7 and 10 (Formative): Group feedback to the whole class, based on Vevox results.

3. Week 8 and 11 (Summative/Formative): In-class MCQs.

To encourage engagement with the feedback, I plan to share some relevant resources with the students in the feedback and then follow up on it later. Another idea is to share in advance of the assessment what is expected of them and share the rubric. It will provide an opportunity to act.

# data[].attributes.body
Continuous Assessment (30%)

- 2x practical assignments/mini projects (first 6 weeks)

- 2x in-class MCQs (last 6 weeks)

Final Exam (70%)

The final exam is categorised as “Assessment OF learning”. It happens at the end of the semester to measure what the student has ultimately achieved. I teach the last 6 weeks of this module and I take 2x in-class MCQs. In the current form, I would categorise them as “Assessment OF learning”. The students attempt the quiz and the same week they receive their grades. This does not provide an opportunity for them to improve their mistakes.

I plan to change this and make these MCQs as “Assessment FOR learning”. My strategy is to first redesign the MCQs based on real-world problem scenarios and to test common “concept confusions”. Secondly, I plan to provide elaborative feedback based on the specific choice they made, so that they can learn from the mistake.

The Assessment Review Toolkit was very useful in identifying several weaknesses. For example, I use rubrics for assessment, but they are never shared with students before the assessment or in feedback. Also, rules regarding the extent of GenAI use for each assessment are not communicated to the students yet.

I plan to update the module and fix the weaknesses identified using the toolkit.

# data[].attributes.body
The readings and activities on inclusive teaching have helped me think more carefully about how I design and teach my classes. I now understand that inclusion should be part of the course from the beginning, not something added later. Small decisions in teaching, communication, and assessment can strongly affect how comfortable and confident students feel in the classroom. I have selected 3 elements from the inclusive teaching checklist which I haven’t used in the past.

- First element that I will use is including a syllabus statement that supports an inclusive learning environment. This helps students feel welcome and respected from the start of the course. It also shows that diversity is valued and that all students are expected to participate and succeed.

- Second element is being fair and transparent in assessment by sharing marking criteria and rubrics. When students can clearly see how their work will be assessed, they feel less confused and less stressed. This is especially helpful for students who are new to university or unfamiliar with academic expectations.

- Third element is using a variety of teaching strategies, including active learning methods. Students learn in different ways, so using different approaches such as discussions, group work, and problem-based activities can help more students engage with the material. Active learning also encourages participation and helps students better understand and remember what they learn.

# data[].attributes.body
I have found Laurillard’s Conversational Framework to be highly valuable as a practical guide for designing effective educational environments. The framework places the learner at its centre, encouraging teachers to consider not only what content they intend to deliver, but also the actions and activities students engage in to develop understanding. The framework emphasises the need to incorporate a range of learning types in order to achieve optimal learning outcomes. Laurillard’s framework provides 6 learning types. In my module each learning type will used but to a different extent.

1. Acquisition

Acquisition will be used in almost every session. It is important for introducing foundational concepts. I will use short, focused lectures with many annotated diagrams to support this learning type.

2. Collaboration

Collaborative learning will be used extensively in cooperative case studies and group-based Think / Pair / Share tasks. Students will work in small groups to tackle problems such as diagnosing web performance issues or evaluating protocol trade-offs. It helps students develop teamwork, communication, and shared problem-solving skills.

3. Discussion

Discussion will be embedded throughout the module using the three active learning activities I designed for this module, namely; 1) Think / Pair / Share 2) Application Activities 3) Categorizing Grid / Pro–Con Grid. This learning type supports conceptual clarification, exposes students to diverse perspectives, and enables learning from peers in a low-stakes environment.

4. Investigation

Investigation-based learning is central to helping students understand system behaviour. Students will engage in Investigation every week both in lectures and labs when analysing QUIC logs, Wireshark traces, benchmarking results, and Core Web Vitals metrics. Students formulate hypotheses about performance issues and test them using evidence, closely mirroring real-world performance engineering practice.

5. Practice

Practice is essential for developing technical competence. Students will apply concepts learned through structured exercises in labs each week using simulation tools.

6. Production

Production is used less frequently. The main activity that involves this learning type is the 45 minutes activity when students:

Produce short performance analysis summaries

Present group findings

Create protocol comparison artefacts and optimisation proposals

# data[].attributes.headline
Longer Active-Learning Activity (45 to 50 minutes)

# data[].attributes.subject
Longer Active-Learning Activity (45 to 50 minutes)

# data[].attributes.body
Topics covered:

QUIC protocol

Congestion control

QUIC logging, debugging, and visualisation

Web performance benchmarking

Core Web Vitals

Tools: Wireshark, qlog, qviz, dev tools

Goals of the activity

Enable the students to:

1. Analyse performance of a web application using protocol-level data.

2. Interpret QUIC logs and visualisations to identify latency, congestion, and packet loss issues.

3. Relate transport-layer behaviour to user-perceived performance metrics (Core Web Vitals).

4. Propose evidence-based optimisations for real-world web systems.

Activity: Diagnosing and Optimising Web Performance in a Soft Real-Time System

Students will be given a realistic industry scenario. This particular scenario is derived from some case studies that are part of this module’s learning material.

Scenario

A large e-commerce platform has migrated part of its frontend traffic to QUIC. Despite improved connection setup times, users in certain regions report poor video preview performance and degraded Core Web Vitals.

You are part of a performance engineering team tasked with diagnosing the issue and proposing optimisations.

Each group receives:

A short network trace (pcap file) that can be analysed in Wireshark

A QUIC qlog file that can be loaded into qviz for visualisation

A simplified Core Web Vitals report (before/after comparison)

A structured worksheet with guiding questions

Task 1: Individual Analysis (10 minutes)

Each student individually reviews the provided artefacts and answers short questions such as:

Identify one potential transport-level issue visible in the QUIC pcap or qlog.

Which Core Web Vital is most affected, and why?

Is the observed issue more likely due to congestion control, packet loss, or application behaviour?

Suggest one protocol-level and one application-level optimisation

Students write brief notes. This phase gives quieter students time to process before group discussion.

Task 2: Cooperative Case Analysis (15 minutes)

Students form groups of 4 to 5. Each group chooses and addresses one of the three different analytical angles:

Group A – Transport Analysis
Analyse congestion window behaviour, RTT variation, and loss events from qlog/qviz.

Group B – Protocol Comparison
Complete a defining-features matrix comparing QUIC and TCP for this scenario (latency, retransmission, head-of-line blocking).

Group C – User Experience Impact
Map protocol-level findings to Core Web Vitals.

Students in each group collaborate on shared worksheets.

Task 3: Group Reporting (20 to 25 minutes)

Each group delivers a ~2-minute verbal summary, addressing:

What evidence they found

How it explains the observed performance metrics

Their proposed optimisation

Other students are encouraged to ask clarification questions or challenge assumptions.

Instructor Role

The instructor will introduce the scenario, clarify expectations, and link the tasks to module learning outcomes. The instructor will walk among the students and facilitate discussion. In the end, summarise key takeaways.

Existing materials:

QUIC protocol documentation

Real-world benchmarking case studies

Tools: Wireshark, qlog, qviz

New materials to be created:

Scenarios

Network traces and qlog files

Core Web Vitals summary report

Structured worksheets

# data[].attributes.body
I teach the second half of CT420 (Real-Time Systems) from week 7 to 12. The main topics are the following:

Week 7 - Multimedia technologies (RTP, WebRTC, Cloud Gaming, Adaptive Streaming)

Week 8 - Modern Protocols  - HTTP/2

Week 9 - Modern Protocols  - QUIC
Week 10 -  Congestion control algorithms

Week 11 - Logging, Debugging and Visulisation of network traffic

Week 12 - Web Performance Benchmarking

Each week there are 2 lectures of 1 hour each. My previous approach to make the lecture interactive and to keep the students engaged was that I frequently asked questions, walked around the classroom, and used Vevox to get students’ input.

To redesign this module and to support students in achieving the learning outcomes, I will now use a new active-learning approach that combines lectures with student-centred activities. I have selected the following activities from the active learning checklist.

1)        Think / Pair / Share

2)        Application Activity

3)        Categorizing Grid / Pro-Con Grid

I have designed these activities to reinforce conceptual understanding, promote application to real-world systems, and develop analytical and collaborative problem-solving skills relevant to the module. Across all sessions, I plan for active student engagement for 10–15 minutes in each lecture. The selected activities are aligned with the technical and applied nature of the module content.

1. Think / Pair / Share

The purpose of this activity is to promote conceptual understanding, misconception checking, and inclusive participation. It is a short activity of around 5 minutes.

It will be used regularly to introduce or consolidate key concepts, particularly in technically dense topics such as soft real-time constraints, multimedia protocols, and congestion control algorithms.

Examples:

·      Multimedia technologies: “Why is occasional deadline miss acceptable in soft real-time multimedia systems but not in hard real-time systems?”

·      QUIC vs TCP: “What design choices in QUIC reduce latency compared to TCP + TLS?”

Students first respond individually in writing, then discuss with a peer, and finally share insights with the wider class. This structure supports students who may be less confident speaking in large groups and encourages reflection before discussion.

For this activity existing lecture slides will be used but new question prompts tailored to module topics will be created.

2. Application Activities

The purpose of these activities is applying theory to real-world systems and performance scenarios. These activities will last for roughly 10 minutes. These written activities require students to apply one or two core principles to realistic scenarios drawn from web and multimedia systems.

Examples:

·      Applying RTP/WebRTC/DASH principles to optimise video streaming under low bandwidth conditions.

·      Analysing how QUIC congestion control would behave under packet loss or high latency.

Students may work in small groups. A short discussion follows the activity to quickly assess understanding.

Scenario-based worksheets will need to be created. Existing teaching material, benchmarking reports and performance studies will be used as reference material.

3. Categorizing Grid / Pro–Con Grid

The purpose of this activity is comparing protocols, technologies, and design trade-offs.

It will roughly take 5 minutes. Students are given a set of scrambled items (protocol features, performance characteristics, design goals etc.) and asked to categorise them under defined headings.

Examples:

·      Categorising features under HTTP/1.1, HTTP/2, QUIC.

·      Categorising performance metrics like latency sensitivity, adaptability, encryption, scalability etc under RTP, WebRTC, DASH.

·      Pro–Con grid comparing delay-based vs loss-based congestion control algorithms for web applications.

This activity encourages structured thinking and helps students visualise differences between closely related technologies.

New grids and handouts will be created. Existing teaching material will be used as a reference.

# data[].attributes.body
A statement is included that outlines how you will use GenAI in the preparation and teaching of the module.

# data[].attributes.body
Here is the revised version of learning outcomes:

LO3 – Design, implement, and validate hard and soft real-time software systems using appropriate scheduling and timing mechanisms.

LO4 – Critically evaluate the design principles and performance characteristics of QUIC and HTTP/3 protocols.

LO5 – Analyse and assess soft real-time systems and multimedia communication protocols with respect to latency, jitter, and quality of service.

These are more detailed, observable and assessable. They also use higher-order verbs from Bloom's Taxonomy.

# data[].attributes.body
Generative Artificial Intelligence (GenAI) tools (ChatGPT, Gemini or others) may be used in this module as a support for learning, provided they are used responsibly and ethically.

Permitted:

To obtain explanations of technical material

To explore examples

To find relevant literature and online resources

To test your understanding by asking GenAI to quiz you or generate practice questions on key topics

Not permitted:

To generate answers that are submitted as your own work

To produce reports, essays, or code for direct submission

To generate review of secondary research and citations

# data[].attributes.body
I have been using GenAI mainly as a learning and research support tool in my CEL261 work. In particular, I use Perplexity AI it to gain deeper explanations of new learning theories introduced in the module and to help identify relevant literature and key authors in the field. It is better and faster than using Google search to manually locate relevant information and articles by searching through hundreds of search results, many of which are usually unuseful links.

# data[].attributes.body
Acquisition (45%) - Students listen to lectures or read material about QUIC, HTTP/3, and other media protocols.

· Investigation (15%) - Critically evaluate and compare performance characteristics of these protocols.

· Practice (25%) – This involves the "Design and Implement" phase. Using a simulator or hardware to test performance mechanisms and receiving feedback from the system.

· Production (10%) - Creating a technical report that "assesses soft real-time systems". This is the student’s output.

· Discussion (5%) - Students discuss and debate the trade-offs of latency vs. bandwidth or the merits of QUIC over TCP etc.

· Collaboration (0%) -  There are no group tasks.

# data[].attributes.body
LO1 - Discuss and differentiate between real-time and safety-critical systems

LO2 - Differentiate between and practically use the time synchronisation protocols NTP and PTP

LO3 - Design and implement hard and soft real-time software systems.

LO4 - Explain and assess the design and performance of QUIC and HTTP3 protocols.

LO5 - Discuss soft real time systems and multimedia protocols.

# data[].attributes.headline
My current approach to assessment in the module I plan to redesign....

# data[].attributes.subject
My current approach to assessment in the module I plan to redesign....

# data[].attributes.body
Add more details below in a comment:

# data[].attributes.wish_content.attachment_props.question
Which of the descriptions is closes to your approach to assessment up to this point? 

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
Assessment is mainly through an essay or large written assignment.

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
Assessment is mainly through an end of semester exam in an exam hall with a little continuous assessment.

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
Assessment is mainly through an oral or practical in person exam.

# data[].attributes.headline
My current approach to lectures in the module I would like to redesign.....

# data[].attributes.subject
My current approach to lectures in the module I would like to redesign.....

# data[].attributes.body
Add more detail as a comment below:

# data[].attributes.wish_content.attachment_props.question
Which of these best describes your typical lecture?

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
I lecture and students are generally quiet occasionally asking questions.

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
I lecture interspersed with discussion where a few students contribute.

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
I lecture some of the time but a good deal of discussion happens where most of the students are actively engaged.

# data[].attributes.wish_content.attachment_props.poll_choices[].choice_text
I lecture some of the time but a good portion of time students work in small groups and we discuss that small group work as a whole class here and there.

# data[].attributes.body
Satisfactory (Green): Practical details of overall teaching load and chosen module provided, including student numbers, ECTS, where the module sits within the programme, limiting factors for the design, and reason for redesign.

Needs Improvement (Red): Missing some basic scene-setting details.

# data[].attributes.body
Satisfactory (Green): Curriculum models presented in class were reflected on with respect to the context of the module under review, discipline and connections to the literature.

Needs Improvement (Red): Models missing, or connection to the literature, module design or discipline not made.

# data[].attributes.body
Satisfactory (Green): Existing learning outcomes have been reviewed. Revised learning outcomes are clear to students, written well, with rationale for change provided. Learning outcomes focused on for the redesign chosen and correspond to approximately 1/2 of a 5 ECTS module.

Needs Improvement (Red): Need to revisit guidelines on writing learning outcomes, revise learning outcomes further, and/or need to specify learning outcomes for redesign.

# data[].attributes.body
Satisfactory (Green): Overall plan provided, and an appropriate level of active learning detailed, rationale for approach justified in literature, clear how overall teaching and learning plan will engage students and provide them with experiences necessary to achieve learning outcomes. Activities Tips and Checklist completed and uploaded to Padlet.

Needs Improvement (Red): More detail needed on the overall teaching and learning plan (justified using literature) that addresses the learning outcomes stated, or insufficient detail provided on active-learning or student engagement, or missing checklist.

# data[].attributes.body
Satisfactory (Green): Overall plan provided, and a specific authentic assessment activity detailed, rationale for approach justified in literature, clear how the assessment plan will determine if the revised learning outcomes were achieved. Details of how assessments will be marked provided with choices justified.

Needs Improvement (Red): Detail not sufficient for overall assessment plan (justified using literature) provided that assesses the learning outcomes stated, one authentic assessment is not provided in detail, or marking approach not provided or justified.

# data[].attributes.body
Satisfactory (Green): Regular feedback on learning (group and/or individual) is planned for the module with details provided. Demonstrate how students will be able to use feedback to improve their work in the module (feedforward).

Needs Improvement (Red): Feedback opportunities not detailed. Unclear that students will be able to use feedback to improve learning.

# data[].attributes.body
Satisfactory (Green): Overall, the elements of this teaching and learning experience, including all aspects of the teaching and learning plan and assessment, work together (or are aligned) to achieve and demonstrate the learning outcomes.

Needs Improvement (Red): Elements of the design are not clearly working together (or aligned) and need further revision.

# data[].attributes.body
Satisfactory (Green): Details were provided of how you would work with your students to promote academic integrity. Assessment vulnerabilities were discussed and addressed.

Needs Improvement (Red): Little details were provided of how students would engage with academic integrity jointly with you. Assessment vulnerabilities were not discussed or addressed sufficiently.

# data[].attributes.body
Satisfactory (Green): The impact of Generative AI was considered throughout the learning design (teaching, learning, assessment, academic integrity, equity and inclusion). A statement is included that outlines how you will use GenAI in the preparation and teaching of the module. A statement is included that outlines what students are allowed to use GenAI for in their learning and assessment for this module.

Needs Improvement (Red): The appropriate approach to Generative AI has not received sufficient consideration in the module design. One or both of the statements is missing.

# data[].attributes.body
Satisfactory (Green): Inclusive teaching checklist completed (uploaded to the T&L Redesign Padlet) and 2-3 new inclusive teaching practices chosen and incorporated into the module redesign.

Needs Improvement (Red): Checklist incomplete, missing, and/or little evidence of inclusive teaching practices in redesign.

# data[].attributes.body
Satisfactory (Green): Plan included for evaluating your teaching (beyond end/mid semester surveys) and how you will use this evaluation.

Needs Improvement (Red): Little provided on evaluating teaching, or limited to end/mid semester survey.

# data[].attributes.body
Satisfactory (Green): Evidence of significant engagement with the literature.  A minimum of 12 references to the literature to include all of the required/assigned readings from CEL261/291. Choices throughout are appropriately justified from the literature.

Needs Improvement (Red): Insufficient references, some references are provided but not referred to in the appropriate section of the T&L Redesign Padlet, or references are not used to justify choices.

# data[].attributes.body
Satisfactory (Green): ESD has been reflected on in the context of this module and 1-2 aspects of this module redesign that support ESD have been highlighted.

Needs Improvement (Red): Reflection on ESD not sufficient and/or aspects of module redesign supporting ESD have not been identified.