> On May 6, 2016, at 11:00 , 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.

        That is what I thought as well, but as I understand now fragmentation 
happens on the IP level independent of the “payload” so fragmentation is all 
the same for UDP/TCP/ICMP. According to 
https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly all packets in 
a fragment group should have the same IP identification value, so matching 
fragmented packets should be even easier, just use the SRCIP, DSTIP PROTOCOL 
IDENTIFICATION quadruple (all values that live in the IP header, or use these 
values to find the matching port from the first fragments protocol header… For 
sanity checking one might even require for all but the last packet to have the 
MF flag set and the fragment offsets to be monotonically increasing. But this 
will require to at least look at the MF flag to notice fragments at all… But I 
guess https://tools.ietf.org/html/rfc6864 says all of this more distinctively…

Best Regards
        Sebastian

> 
> David Lang

_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to