Detail questions on dash-handling-fragmented-packets.md

[jfingerh]

These statements are made in the latest version of that file as of 2022-Feb-23:

• 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.

• If the connection is closed with the arrival of the FIN packet then all temporal flows must be closed as well.

The last statement seems to be assuming that temporal flows can be associated with a 5-tuple. That is true if the first IP fragment arriving for one original unfragmented packet contains the L4 header.

Is there a preferred behavior if the first IP fragment for a particular (Frag ID, DST, SRC) tuple is a non-first fragment, and contains no L4 header information, and thus cannot be associated with a particular 5-tuple (at least not yet)?

[jfingerh]

Another question that might be useful to answer in that same document: Is there some maximum IP fragmented packets per second maximum requirement for a DASH compliant product, that might be much much lower than "line rate" for the product? e.g. something like "if a DASH device received more than 50K IP fragmented packets per second, it may discard all of those exceeding that rate".

If you want DASH compliant products to handle IP fragmented packets at line rate indefinitely, it would be good to state that explicitly.

[jfingerh]

Discussion of this issue in 2022-Feb-23 DASH test work group meeting, Gerald said that if:

• an IP fragment arrives to the device when it has no matching (Frag ID, DST, SRC) tuple
• the IP fragment is not the first fragment

then a DASH product should drop such a packet, and not create a (Frag ID, DST, SRC) state for that fragment. @KrisNey-MSFT completed this piece 2/27/2022

[jfingerh]

AI for @jfingerh to create a PR for the dash-handling-fragmented-packets.md document that makes this as explicit as possible.

This AI is done here: #64

As mentioned in a comment there, my expectation is that the PR might be closed without being merged. The main purpose of creating it is for the consideration of Microsoft engineers who will do a detailed review of that document for correctness and completeness.