On Fri, 6 May 2016, Stephen Hemminger wrote:
On Fri, 6 May 2016 02:00:02 -0700 (PDT)
David Lang <[email protected]> wrote:
On Fri, 6 May 2016, moeller0 wrote:
Hi Jonathan,
On May 6, 2016, at 06:44 , Jonathan Morton <[email protected]> wrote:
On 6 May, 2016, at 07:35, Dave Taht <[email protected]> wrote:
this would be a pretty nifty feature for cake to have in this hostile universe.
Yes, but difficult to implement since the trailing fragments lose the
proto/port information, and thus get sorted into a different queue than the
leading fragment. We would essentially need to implement the same tracking
mechanisms as for actual reassembly.
But the receiver needs to be able to re-segment the fragments so all
required information needs to be there; what about looking at src and dst
address and the MF flag in the header as well as the fragment offset and scrape
proto/port from the leading fragment and “virtually” apply it to all following
fragments, that way cake will do the right thing. All of this might be too
costly in implementation and computation to be feasible…
wait a minute here. If the fragments are going to go over the network as
separate packets, each fragment must include source/dest ip and source/dest
port, otherwise the recipient isn't going to be able to figure out what to do
with it.
David Lang
Fragments are reassembled by IP id, not src/dest port.
Only the first fragment has the L4 header with src/dest port,
all the rest are just data.
That is why most firewalls reassemble all packets (and then refragment as
needed)
to allow matching on port values.
actually, many firewalls do not reassemble packets, they pass packets through
without reassembly.
what IP id are you referring to? I don't remember any such field in the packet
header.
David Lang
For several cases where flow information is necessary most code does:
flowid = is_fragementd(ip) ? ip->id : hash(ip + tcp)
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
