> -----Original Message----- > From: Bruce Lowekamp [mailto:[email protected]] > Sent: Tuesday, December 16, 2008 12:10 PM > To: Narayanan, Vidya > Cc: Hardie, Ted; Eric Rescorla; [email protected] > Subject: Re: [P2PSIP] RELOAD fragmentation > > 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
Yes, this is what I meant with doing a overlay size estimation and sizing the message accordingly. But, obviously, it has the problem you talk about below with varying MTUs. I don't think this is a solution worth considering. > 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). 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). > I don't see the similarity of the problem with destination list - in the case of a destination list, the originator of the message deals with the largest size that message will get to - so, fragementation at the sender works here. Or, am I missing something? > 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 Hmmm.. I am not sure about that. I don't think keeping state is necessarily more complex. Even with fragmentation, you'll need timeouts to handle the DoS attacks Ekr was talking about - so, in either case, you have state that needs to timeout. OTOH, keeping forwarding state reduces the lookup latency as opposed to dealing with fragmentation and reassembly at the intermediate peers. - Vidya > 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
