In particular with NATs, you can't rely on fragments being received. Bruce
On Tue, Dec 16, 2008 at 4:38 PM, Narayanan, Vidya <[email protected]> wrote: > 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
