John,
At 20:39 03/01/2007, John Heffner wrote:
Originally we had thoughts of trying to prescribe an implementation fix.
I still think this is the way to go. ...Well, at least not actually
prescribing the algorithm, but prescribing (or recommending) its desired
behaviour.
There are certainly a lot of possible approaches. Linux has just
recently implemented a scheme where fragments time out not by wall clock
time, but by the number of intermediate packets received, effectively
having a tunable parameter on the amount of reordering tolerated. This
seems to work pretty well.
That's nice. I was only using wall-clock time because it was a strictly
monotonically increasing number. Concatenating an increasing index would
work just as well (in fact better), which is effectively the same as the
Linux idea. And yes, I was imagining that the receiver would adapt the
allowed gap between re-assembled packets to circumstances (ie tunable could
mean per flow, rather than configured per machine).
Heuristically tuning this parameter per flow could potentially even handle
the problem you mention where the sender is spreading PacketIDs over other
faster flows. Tho, having heuristic adaptation in an IP stack is a bit
scary - how many vulnerabilities might that open up?
However, there really is a protocol problem that prevented us from trying
to prescribe a solution. The sender is responsible for not reusing IPIDs
before the fragments time out, but the receiver is responsible for timing
out fragments. There is no way to the sender to know if a receiver has
timed out the old fragments yet.
This is only a 'real protocol problem' if we define a correct re-assembly
function as one that is exactly 100% reliable. Even if a well-known timeout
had been standardised (whether 15mins, 1min, 1sec), re-assembly wouldn't
have been guaranteed reliable. It would only be possible to guarantee that
received packets were not re-using a number before a time agreed between
sender & rcvr if we used loose clock synch (e.g. I did one like this myself
in RFC4082).
I don't believe anyone wants IP to take that road. So strictly, we don't
have a real protocol problem, if 100% is an unattainable goal anyway at
reasonable complexity.
So, firstly we need to state up front that IP fragment re-assembly is not
expected to be exactly 100% reliable. Then we can say a lot can be done
through good implementation to get within a gnat's tittle of 100%.
As an operations person, I might be able to deploy fragmentation with some
confidence if I can ensure that all receivers I'm using are running recent
Linux kernels with the workaround enabled. But as an application
developer, there's no way for me to be sure I won't ever run in to
protocol trouble if I rely on fragmentation.
An app developer can always say "rcvr app requires at least Linux vX.Y,
Windows 2052 etc".
The only property we (the IETF) need to ensure is that highly reliable
reassembly doesn't rely on sender behaviour as well. Even with
pseudo-random PacketID sequences, I think that's do-able by building on
implementations like the Linux one above.
Bob
____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe, Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
