At 12:09 PM -0800 12/16/08, Bruce Lowekamp wrote:
>The two problems are the growth of the via list and route logging.
>Like you've suggested, it's impossible to figure out how long the via
>list needs to get. There are some hackish possibilities like allowing
>extra room in the first fragment for the via list to grow and letting
>the first fragment be re-fragmented if the via list grows beyond the
>MTU of subsequent hops (since MTU can drop, always need to support
>that behavior, anyway).
The behavior I was assuming (and did not state well--sorry) was that
you could allot a certain amount to the via list and reassembly/refragmentation
would occur only if the via list growth forced it. This gets a little
more difficult if there are two headers (via list and route logging),
but I think it does work.
This is a hack (politely, I guess I could call it a "hybrid solution"),
but it does allow common cases to go forward without reassembly
and refragmentation (any case where the amount of growth
allotted was sufficient) while handling the less common case
of an addition causing an over-run.
>Another option would be to reorder the
>message so that the via list is at the end (although there's a similar
>problem with the destination list being too long, anyway).
Any particular reason not to do this?
Ted
>So I think there are some solutions to having the intervening peers
>keep state, but the complexity concerns me. It's a lot simpler to
>have intermediate peers reassemble and maybe do something like
>restrict the amount of buffering required per connection, which seems
>reasonable if we require the sender not to interleave frags from
>different messages. (Obviously the network can still reorder, but I
>think we can establish a reasonable bound on that.)
>
>Bruce
>
>On Tue, Dec 16, 2008 at 2:35 PM, Narayanan, Vidya <[email protected]> wrote:
>>>
>>> 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.
>>>
>>
>> Maybe I'm missing something basic here. How would the sending node even
>> know that the via list was rendered completely at any time?
>>
>> Regards,
>> Vidya
>>
>>> 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
>> _______________________________________________
>> P2PSIP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
