Question for the group, do we have scenarios where we expect peers to be have enough in-progress messages that they would exceed their memory available for storing state? This would have to involve high bandwidth peers with low amounts of memory (or a very long end-to-end timeout on transactions).
I want to like this solution, but I'm concerned that there may be scenarios where it doesn't work. I'm also concerned that buffer parameters that work fine under normal overlay behavior would make it very easy to DoS a peer with only a couple of compromised nodes in the system. Bruce On Tue, Dec 16, 2008 at 5:23 PM, Narayanan, Vidya <[email protected]> wrote: > Yep - I was just reminded of this same issue by one of our developers as well > :) > > I like Salman's option of S1 with S4 (intermediate nodes maintain state for > symmetric routing; fragmentation/reassembly done e2e). Even for this, I > think we would need to specify an error that can be returned by an > intermediate node that may realize that the fragment is too big to be sent > over the next link (similar to IPv6 PMTU discovery using the ICMPv6 Packet > Too Big packet). > > We are then talking about always setting the DF bit for IPv4 and avoiding any > fragmentation at IPv6 as well. > > Vidya > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:[email protected]] >> Sent: Tuesday, December 16, 2008 2:01 PM >> To: Narayanan, Vidya >> Cc: [email protected] >> Subject: Re: [P2PSIP] RELOAD fragmentation >> >> 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
