Free / Grades 6-7, with arithmetic support
Message Route Studio
How can we tell whether a message arrived completely, not just quickly?
4 flexible sessions / about 155 minutes including practice / network models, rates and evidence-based explanations
Suggested rhythm: two sessions a week for two weeks. Week 1: pieces and performance. Week 2: delivery evidence and a final demonstration. Work on paper, speak or dictate; take longer when useful.
Reading, watching and paper activities are free. Parents and instructors can save a collection; scheduling it for a student requires Plus or Lifetime. No upload is required.
Before you begin
Order numbered items, add and subtract whole numbers, divide by small whole numbers and compare measurements with matching units. A calculator is welcome after choosing the operation.
Paper networks, no device changes. No network scanning, device settings, passwords, real addresses or personal messages are needed. All tests are invented paper records. Do not contact example addresses. Card labels, delivery rounds and resend rules are a teaching model, not a real packet format or a guarantee that every Internet protocol delivers messages.
Materials
- 4 sheets per learner: Project journal
Print four pages or copy the headings into a notebook.
- 2 sheets per learner: First explanation and final report
Keep both versions on notebook pages or clean scrap paper. Draw cards rather than cutting them.
- 1 per learner: Pencil
Speak, dictate, point or use an accessible writing tool.
- 1 shared, optional: Calculator
Use written arithmetic and label units.
- 1 shared: Browser or printed pages
Read the existing lesson transcripts and paper evidence together. Separate worksheet printing is optional.
Choose the support that fits
- More support: draw one box per expected position and place each label beside its matching box. Keep delay and capacity in separate columns.
- More challenge: design a new invented record with a duplicate and a missing piece, retaining a correct answer key and explicit stopping rule.
- Access options: point, dictate or explain aloud. Color, cutting, handwriting, uploading, recording and public presentation are not required.
What good evidence looks like
- Check message identity and every expected position.
- Distinguish a duplicate from a missing piece.
- Compare delay and capacity using matching units.
- Separate lookup, delivery and confirmation evidence.
- Demonstrate a revision and state what the paper model leaves out.
These are discussion criteria, not a new automatic score. Existing lesson and worksheet records keep their own subjects. Checking off a planned task does not demonstrate mastery or add a second grade.
Session 1 / about 40 minutes
Rebuild the right message
Goal: Reconstruct a paper message by identity and position, detecting a duplicate, an unrelated piece and a missing position.
Preparation / about 7 minutes of adult support: Have journal 1 and a first-explanation sheet ready. Draw labeled boxes; no scissors or real messages are needed.
Our paper rule states the message label and expected number of pieces. A separate message T has three pieces: T/1 SEND, T/2 THE BLUE, T/3 BOX. If they arrive 3, 1, 2, read them in position order, not arrival order. A second T/2 is still position 2; U/3 belongs to a different message. Count distinct matching positions, not cards. Otherwise a very confident pile of duplicates could claim to be a complete message. Keep an empty box when evidence is missing.
Why does receiving three cards not necessarily complete a three-piece message? What information is needed before checking completeness?
- Packet puzzles: order the pieces / about 10 minutes
- Put a Packet Message Back in Order / about 10 minutes
- Reconstruct my paper message / about 20 minutes
Fun fact: TCP gives an application ordered bytes even when its network deliveries arrive out of order. Our word cards illustrate ordering, but TCP numbers bytes rather than these classroom cards. Source
S3U / Message Route Studio / Journal 1 of 4
Different cards, different evidence
Message R needs positions 1 through 4. Arrivals are R/3 THE, R/1 PLEASE, R/3 THE again, S/2 RED and R/4 MAP. The sender later supplies R/2 BRING. All matching duplicates have identical content.
| Check | My evidence and explanation |
|---|---|
| Matching positions before the later piece | |
| Duplicate and unrelated piece | |
| Missing position before the later piece | |
| Completed message after R/2 arrives |
Why could five arrivals still leave this four-piece message incomplete?
Keep a first explanation on another sheet: what evidence proves completeness in this model, and what would still be unknown about real delivery?
Session 2 / about 40 minutes
Separate delay from capacity
Goal: Compare delay and data-carrying capacity, calculate ideal serialization time and keep that calculation separate from real completion time.
Preparation / about 8 minutes of adult support: Have journal 2 ready. Use only the invented measurements. Read megabits and seconds aloud; do not substitute megabytes.
A delay is a wait; capacity is how much data a link can carry per second. In a separate example, path C has 15 milliseconds of delay and 5 megabits per second capacity; D has 45 milliseconds and 20 megabits per second. C has less delay; D has more capacity. Sending 40 megabits onto an ideal continuously available link takes 40 divided by 5 = 8 seconds for C or 40 divided by 20 = 2 seconds for D. This serialization calculation excludes lookup, travel, setup, overhead, competition and retries. It is not a download-time promise. A wider doorway does not make every journey shorter.
Which measurement helps compare waiting for a small response? Why is data divided by capacity not the entire time a real download takes?
- Network delay and capacity / about 10 minutes
- Names, Addresses and Network Delays / about 10 minutes
- Compare two fictional paths / about 20 minutes
Fun fact: Bandwidth describes capacity; throughput describes the rate actually achieved. A connection can have spare capacity while another part of the system keeps it waiting. Source
S3U / Message Route Studio / Journal 2 of 4
Two measurements, not one winner
Path A has 20 milliseconds of delay and capacity 8 megabits per second. Path B has 60 milliseconds and 24 megabits per second. For a separate ideal calculation, serialize 96 megabits at full constant capacity. Ignore all other time and overhead in that calculation only.
| Comparison | My calculation, units and limit |
|---|---|
| Lower delay; difference in milliseconds | |
| Greater capacity; how many times A? | |
| Ideal serialization time on A | |
| Ideal serialization time on B |
Why do these values not identify one path as best for every task?
Name two things omitted from the ideal calculation. Why should its result not be advertised as a guaranteed download time?
Session 3 / about 35 minutes
Read a delivery record
Goal: Separate name lookup from reaching a service and distinguish what a sender knows from what a receiver has actually received.
Preparation / about 7 minutes of adult support: Use journal 3 and the supplied invented log only. No account, address lookup, connection test or device access is needed.
DNS can look up address information for a name; finding an address does not prove a later service request succeeded. A separate paper log says lookup succeeded, then connection failed: those observations can both be true. Confirmation is another step. If a receiver has all pieces but its confirmation is lost, the receiver has the message while the sender still lacks confirmation. Silence alone does not tell the sender which step failed. Our paper sender waits one round, then retries once and stops if still unconfirmed. Real protocols use more detailed rules; repeating forever is not our plan.
What does each side know? Why should a missing confirmation be reported as uncertainty rather than proof that the receiver has nothing?
- Separate lookup from service access / about 10 minutes
- Compare sender and receiver evidence / about 15 minutes
- Write a bounded retry rule / about 10 minutes
Fun fact: The address 192.0.2.10 belongs to a range reserved for examples in documentation. An example address is for explaining a network, not a destination to test. Source
S3U / Message Route Studio / Journal 3 of 4
Received is not the same as confirmed
Log X: lookup succeeds; connection fails. Log Y: receiver gets all of Q; its confirmation is lost. After one waiting round the sender retries Q once. The receiver recognizes the identical duplicate and sends confirmation again; this one arrives. No other facts are supplied.
| Evidence checkpoint | What is known; what is not? |
|---|---|
| X: lookup and connection results | |
| Y: receiver after the first delivery | |
| Y: sender before the retry | |
| Y: sender after the second confirmation |
Does log X prove the cause of the connection failure? Explain without blaming a device or a person.
If the second confirmation were also lost, stop after the one allowed retry. What should the sender report, and what could still be true at the receiver?
Session 4 / about 40 minutes
Demonstrate a better paper protocol
Goal: Test a completeness rule against misleading arrivals, revise it using evidence and explain the limits of the final paper protocol.
Preparation / about 8 minutes of adult support: Bring all journals and the first explanation. Use a final-report sheet or a private spoken demonstration. Nobody is monitoring live.
Test a rule using evidence that might break it. In a separate case, message V needs positions 1 to 3 but arrivals are V/1, V/1 and W/3. The rule "three cards means complete" fails: only one matching position is present. A better rule checks the message label, valid positions and all expected distinct positions. If two copies of one label disagree, do not choose the prettier word; mark a conflict and seek clarification. A receiver can show its evidence without claiming to know every event elsewhere. Keep the first rule so the improvement is visible.
Show a counterexample to the first rule, then test the revised rule on both complete and incomplete arrivals. Which real networking problem is still outside this model?
- Find a counterexample to my rule / about 15 minutes
- Demonstrate my revised delivery rule / about 15 minutes
- Revise my first network explanation / about 10 minutes
Fun fact: Two logs can disagree about certainty without either being dishonest: the receiver may have the data while the sender has not received confirmation. Source
S3U / Message Route Studio / Journal 4 of 4
My protocol and its evidence
Message Z needs positions 1 through 3. Test A: Z/2 BLUE, Z/1 SEND, Z/2 BLUE. Test B: Z/3 NOW, Z/1 SEND, Z/2 BLUE, W/2 GREEN. Test C: Z/1 SEND, Z/2 BLUE, Z/2 GREEN, Z/3 NOW. Matching duplicate content is required; conflicts must be flagged, not guessed.
| Test or rule | My evidence and decision |
|---|---|
| A: complete or missing? | |
| B: complete or unrelated? | |
| C: consistent or conflicting? | |
| My revised completeness rule |
Demonstrate your rule on A, B and C. Explain why counting arrivals alone fails and why receiving all positions is not enough when contents conflict.
Compare with your first explanation. What changed or stayed sound? Give one limitation: this model does not implement real TCP, security or a whole Internet connection.
What changed in your explanation?
Show your evidence, explain one revision, and choose a question to investigate next. You can keep everything on paper.
Optional: record actual offline learning in Learning Records. Keep reported minutes separate from website time. For an assigned pack, use your existing daily tasks; this page does not award additional completion credit.