At 10:08 AM -0800 12/12/08, Eric Rescorla wrote:
>The author team has been trying to flesh out the RELOAD fragmentation model and
>we're considering whether it needs a rethink. This is principally an
>issue for UDP.
>
>Briefly, the current model is as follows:
>
>- Nodes communicate to each other by encapsulating every RELOAD message
> in a FramedMessage (see 5.4.1.2). These are acknowledged at the
> hop-by-hop level. Each FramedMessage contains a complete RELOAD message
> or ACK.
>- If a message exceeds the maximum size that a node feels it can send
> to an adjacent node (this principally is an issue for UDP), it is expected
> to fragment it. Each fragment replicates the ForwardingHeader.
>- Intermediate nodes are not expected to reassemble fragments.
>
>The bits on the wire aren't fully fleshed out, but this is what we had in
>mind.
>
>Unfortunately, it's not clear that this works. Unlike IP (except with LSRR),
>the RELOAD header grows and could potentially exceed the MTU all on its
>own. So, it's not clear how to handle that case.
Is this growth primarily in the via list? If that is the case, then it
seems possible to solve this using a combination of the fragment
field and the via list. If the fragment field's high order two bits
indicate that this is a fragment, you could replace the via list
with a null list for any fragment after the first complete rendering
of the via list. That requires one more state in the fragment field
(via list not yet complete;via list complete). It also requires you
to presume that the via list can be split across fragments and
and that fragments with "via list not yet complete" set are
going to have no real data--just segments of the via list--in them.
The same things can be done when other headers grow, obviously;
it is just a bit easiert to do when it is only one header that has to
be tracked in this way.
regards,
Ted
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
