From f2e9dc51463094deb293695ccfa5b6bc4c4de5a5 Mon Sep 17 00:00:00 2001 From: Andy Fingerhut Date: Wed, 23 Feb 2022 23:37:03 -0500 Subject: [PATCH 1/2] Minor clarification on handling of fragmented packets --- .../general/design/dash-handling-fragmented-packets.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/documentation/general/design/dash-handling-fragmented-packets.md b/documentation/general/design/dash-handling-fragmented-packets.md index 1c9b453bb..47f15ac06 100644 --- a/documentation/general/design/dash-handling-fragmented-packets.md +++ b/documentation/general/design/dash-handling-fragmented-packets.md @@ -123,10 +123,13 @@ The figure below shows the TCP header format. For more information, see [RFC 793 result in an **entry** into the **flow table** to **enable fast path processing** for the duration of the connection. -1. If a subsequent packet arrives that is the start of a fragmented packet, the +1. If a subsequent packet arrives that is the first fragment of a fragmented packet (i.e. the Fragment Offset field is 0), the **Frag ID** must be used to create a **new temporal flow** that can be **uniquely identified** by the (**Frag ID**, **DST**, **SRC**) tuple. +1. If a packet arrives that is a non-first fragment (i.e. the Fragment Offset field is not 0), and there is not already a **temporal flow** that matches +this packet, the packet must be dropped. + 1. The temporal flow should be **maintained until the last fragment arrives** or the flow is **aged**. From 3f908e6c3bb5ee866034a53de680992cc846662c Mon Sep 17 00:00:00 2001 From: Andy Fingerhut Date: Thu, 24 Feb 2022 00:18:31 -0500 Subject: [PATCH 2/2] More proposed details on IP fragment handling. --- .../general/design/dash-handling-fragmented-packets.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/documentation/general/design/dash-handling-fragmented-packets.md b/documentation/general/design/dash-handling-fragmented-packets.md index 47f15ac06..9c783d6ff 100644 --- a/documentation/general/design/dash-handling-fragmented-packets.md +++ b/documentation/general/design/dash-handling-fragmented-packets.md @@ -126,9 +126,14 @@ processing** for the duration of the connection. 1. If a subsequent packet arrives that is the first fragment of a fragmented packet (i.e. the Fragment Offset field is 0), the **Frag ID** must be used to create a **new temporal flow** that can be **uniquely identified** by the (**Frag ID**, **DST**, **SRC**) tuple. +This **temporal flow** must record the relevant layer 4 header fields +from the packet that are needed for classification, e.g. source & +destination port, for retrieval by later arriving non-first IP +fragments that match this **temporal flow**. 1. If a packet arrives that is a non-first fragment (i.e. the Fragment Offset field is not 0), and there is not already a **temporal flow** that matches -this packet, the packet must be dropped. +this packet, the packet must be dropped, and no **temporal flow** will be +created. 1. The temporal flow should be **maintained until the last fragment arrives** or the flow is **aged**.