Going back to the basics here - is there a reason we cannot let IP handle fragmentation for UDP messages and keep the added functionality to just reliability?
Maybe I'm missing something fundamental - but, it seems like as inefficient as that may actually be, it might be the simplest solution to the problem. Thoughts? Vidya > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Narayanan, Vidya > Sent: Tuesday, December 16, 2008 12:35 PM > To: Bruce Lowekamp > Cc: [email protected] > Subject: Re: [P2PSIP] RELOAD fragmentation > > > -----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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
