Updated tuple which is used to uniquely identify a temporal flow.

documentation/general/design/dash-handling-fragmented-packets.md

@@ -125,18 +125,18 @@ processing** for the duration of the connection.
 
 1. If a subsequent packet arrives that is the start of a fragmented packet, the
 **Frag ID** must be used to create a **new temporal flow** that can be
-**uniquely identified** by the (**Frag ID**, **DST**, **SRC**) tuple.
+**uniquely identified** by the (**Frag ID**, **DST**, **SRC**, **Protocol ID**) tuple.
 
 1. The temporal flow should be **maintained until the last fragment arrives** or
-the flow is **aged**.
+the flow is **aged** or the connection is **closed**.
 
 1. The aging of a temporal flow **could be different than the connection**
- itself as the packets are close together and generated over a small period of
+ itself as the packets are closed together and generated over a small period of
  time.
 
 1. It is also possible to have **several frames in flight** and hence there may
 be **several temporal flows**, however they can be **uniquely identified** by
-the (Frag ID, DST, SRC) tuple as each frame will have a different Frag ID.
+the (Frag ID, DST, SRC, Protocol ID) tuple as each frame will have a different Frag ID.
 
 1. Although this will result in more flow entries **these flows will likely live
 for `usecs/msec`** and can be aged much quicker than a connection.
@@ -148,6 +148,24 @@ time-out.
 1. If the connection is closed with the arrival of the **FIN packet** then all
 **temporal flows must be closed** as well.
 
+## Stats/Counters
+The temporal flow should also support packet and byte counters.  This data should
+be rolled/added back into the original/parent flow once the temporal flow is removed.
+
+## Other considerastions
+
+1.  When a first fragment (with L4 header) arrives, a new temporal flow should be created.
+This temporal flow should be associated (need to mainatin some state) with the
+**original/parent** flow against which the first fragement was matched.  This
+**association/relationship** will be used in an event when the parent flow is removed
+(age-out, closed, etc.) before the temporal flow is deleted.
+
+1.  If the second fragment (first packet without L4 header and non-zero fragement offset)
+arrives before the first fragment, there will be no temporal flow entry and we will have a
+**flow-mis**.  This may take the **packet processing** to the slow-path.  The slow-path
+should drop this packet.  Since there is no 5-tuple information available, against which
+**bucket** will we count these drop packets in the slow path?
+
 ## Issues and Nuances
 
 1. A connection that is reset should also result in the related