If we must use symmetric routing, then I also think s1 or s4 would be better.
However, I have some additional thought, that there are routing modes that we need not to use the via-list or route-list, such as overlay native routing. Best Regards, Haibin Email: [email protected] Skype: alexsonghw >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Narayanan, Vidya >Sent: Wednesday, December 17, 2008 6:24 AM >To: Bruce Lowekamp >Cc: [email protected] >Subject: Re: [P2PSIP] RELOAD fragmentation > >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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
