(Replies to both Ted and Vidya's messages below) On Tue, Dec 16, 2008 at 3:21 PM, Ted Hardie <[email protected]> wrote: > 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. >
Yeah, I think I agree it can work. Will be a little bit tricky (especially with the route log at the end and via list at the beginning) coming up with headers that can express what's going on, but I think it can be done. We probably need to work out a complete solution and then see whether the complexity is worthwhile. > 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? The current spec says that the via list grows in the route header at the front and the route log is appended to the back. Then the via list can just be swapped with the destination list to route the reply. We could say that both route log and via list are part of the same structure at the end of the message, but then assembling the destination list becomes significantly more complicated (and unnecessarily so in the common case, unless we just view fragmented messages as an entirely different format). On Tue, Dec 16, 2008 at 3:34 PM, Narayanan, Vidya <[email protected]> wrote: >> -----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? > The destination list could be longer than the first frag. So at some point, a peer will have to wait for the second frag and either reassemble or just have all future peers buffer until they know where to route the reply. >> 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. > Sorry, I didn't word that clearly. I'm concerned about the complexity of doing on-the-fly refragmentation as the via list grows. I think keeping state is pretty simple. It just a question of the amount of state required and the potential for attacks. So it seems like we're discussing 3 options: 1) add to/change the protocol so that on-the-fly refragmentation, via-list appending, and destination list reassembly work 2) store forwarding state on the on-path peers so the via list doesn't have to grow 3) reassemble the message at each hop. any of those will work. I think 2 and 3 are both rather simple to specify and implement, although 2 has some state size concerns and 3 will slow down performance. 1 I think is harder to specify and implement, but has fewer of the drawbacks of 2 and 3. Bruce > - 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
