> -----Original Message----- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 21, 2007 2:16 AM > To: Narayanan, Vidya > Cc: Magnus Westerlund; Internet Area > Subject: RE: [Int-area] Lifting up a filter discussion from Monami6 > > On Tue, 20 Feb 2007, Narayanan, Vidya wrote: > >> Maybe filter signalling is sufficiently more restricted case of > >> piggybacking arbitrary data that devising framing, PMTUD, > etc. for it > >> is simpler. I might agree with that if the filters were > restricted > >> to be (say) less than 500 bytes so that no fragmentation was never > >> needed. > > > > Maybe I am missing something here, but, how does UDP help with > > fragmentation? The alternative proposed at the transport > layer seems > > to be UDP-based. > > If a packet carries data or signalling from a single > application only, handling correct packetization of data that > application may wish to send is rather straightforward > because just one application needs to be concerned. > > If a packet may carry data from multiple sources (e.g., > MIPv6, filters, even arbitrary applications) every one of > these will need to be involved and interact in the > packetization process. > > However, the second case gets simpler if you'd use MTU=1280, > disable PMTUD, and fragment every packet that exceeds the MTU > without trying to optimize the payloads such that no > fragmentation was necessary. > > Maybe this was the model you were suggesting and a reason for > the disconnect. >
Ah! Yes, I didn't think the payloads will be optimized to avoid fragmentation. Also, I'm not sure if the filter rules in this case would be handled as a separate application. Perhaps each application (MIP6 or MOBIKE or SHIM6) that would carry the filter rules would have to handle processing of the same? Ultimately, the filter rules are meant to be used by one of these applications anyway. Vidya > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
