Re: Signaling Message Fragmentation

>   1) How big??

Still no answer. I guess then we will have to assume 64KB.
Anything larger than that will have to go as a jumbogram.

Thanks - Fred
[email protected]

> -----Original Message-----
> From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L
> Sent: Tuesday, September 23, 2014 10:30 AM
> To: Sri Gundavelli (sgundave); [email protected]
> Subject: Re: [DMM] Signaling Message Fragmentation
> 
> Hi Sri,
> 
> I will make this even easier and reduce it to a single question:
> 
>   1) How big??
> 
> Thanks - Fred
> [email protected]
> 
> > -----Original Message-----
> > From: Templin, Fred L
> > Sent: Tuesday, September 23, 2014 8:51 AM
> > To: Templin, Fred L; Sri Gundavelli (sgundave); [email protected]
> > Subject: RE: Signaling Message Fragmentation
> >
> > Sri,
> >
> > > I've seen some work on IPSecme WG on IKEv2 message fragmentation
> > > for the same issue.
> >
> > I looked at this, and the approach is roughly the same as what I have
> > been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
> > years. In other words, perform fragmentation and reassembly at a level
> > above the encapsulating IP protocol headers and below the encapsulated
> > IP protocol headers - a mid-layer fragmentation and reassembly.
> >
> > So, this brings up a few questions:
> >
> >   1) Does the concern apply only to large control messages, or also to
> >      large data packets?
> >   2) How big can the control messages get - not only for just today but
> >      also going forward into the future?
> >   3) Are we really so concerned about IP fragment dropping that we need
> >      to bump this up to a mid-layer frag/reass?
> >
> > Thanks - Fred
> > [email protected]
> >
> > ---
> >
> > From: dmm [mailto:[email protected]] On Behalf Of Templin, Fred L
> > Sent: Monday, September 22, 2014 4:45 PM
> > To: Sri Gundavelli (sgundave); [email protected]
> > Subject: Re: [DMM] Signaling Message Fragmentation
> >
> > Hi Sri,
> >
> > My understanding is that if a source sends fragmented messages it must have assurance
> > that the destination has a large enough reassembly buffer. Since the minimum IPv6
> > reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented packets
> > larger than 1500 bytes unless there is some other means of determining whether the
> > destination's reassembly buffer can accommodate the larger size.
> >
> > How big do you need?
> >
> > Thanks - Fred
> >
> > From: dmm [mailto:[email protected]] On Behalf Of Sri Gundavelli (sgundave)
> > Sent: Thursday, September 18, 2014 1:04 PM
> > To: [email protected]
> > Subject: [DMM] Signaling Message Fragmentation
> >
> > [Discussion under the maintenance scope]
> >
> > With the standardization of all the new mobility options (ANI, QoS, IFOM, MNP..etc)   and specially
> > with the NAI/Domain type fields in some of those options, we are almost close to hitting the PBU/BU
> > fragmentation limit.
> >
> > Any thoughts on how to deal with this ? How is it solved in other message based protocols ? I've
> seen
> > some work on IPSecme WG on IKEv2 message fragmentation for the same issue.
> >
> > Should we do some thing here ? Or, if any one has invested time on this and has a proposal ?
> Comments
> > ?
> >
> >
> >
> > Regards
> > Sri
> 
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm