Should have included a reference for that, since TSVWG actually included a discussion in their recent UDP guidelines doc.
http://tools.ietf.org/html/rfc5405#section-3.2 Bruce On Tue, Dec 16, 2008 at 4:58 PM, Bruce Lowekamp <[email protected]> wrote: > 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
