Subject: Re: Fragmentation

From: Luca Martini <[email-masked]>
Date: Thu, 25 Jul 2002 15:10:40 -0600

yes , and keep in mind that many newer devices do not even have a slow path.
All they have is a management CPU.

In the past Small MTU networks might have been a problem , but today almost all 
devices support some kind of enlarged MTU. ( thanks to MPLS requirements )
I don't see fragmentation as a significant requirement.

Luca

Eric Rosen wrote:

> Scott> If  mandatory to implement,  you can  still use  slowpath even  if it
> Scott> doesn't work well
> 
> I'd have to disagree with this.  
> 
> I think that fragmentation is only needed on a frame relay pseudowire if (a)
> the CEs  are supporting a large  MTU, (b) the CEs  cannot themselves support
> frame relay  fragmentation, (c) it is  infeasible to change the  MTUs on the
> CE.
> 
> In this situation, there is no  reason to suppose that fragmentation will be
> uncommon; indeed, it might be quite common. 
> 
> It  is only acceptable  to implement  a feature  in slowpath  if its  use is
> uncommon. 
> 
> What  I  conclude  is  that  there  is  no  point  to  providing  fragmenta-
> tion/reassembly for  frame relay  pseudowires in slowpath.   If it  can't be
> provided in fastpath, you might as well omit it. 
> 
> Stewart> Some applications require fragmentation
> 
> I think the important question is whether Service Providers have any use for
> a PWE3 mechanism which can't  fragment.  In deploying such a mechanism, they
> would have to specify the MTU,  and they wouldn't be able to provide service
> to customers that require a larger MTU. 
> 
> Stewart> Fragmentation  (well  normally   re-assembly)  is  memory  and  CPU
> Stewart> intensive and some hardware designs cannot support it. 
> 
> This  is  certainly  true  of  IP   reassembly.   But  if  we  have  a  PWE3
> fragmentation function  in which it is  allowable to discard a  frame if its
> fragments do not arrive in order, it's not quite as difficult, especially if
> we can  start transmitting a frame to  the CE before all  the fragments have
> arrived. Of course, it's still far from being free.
>           
> Stewart> My  view  is  that  the  baseline should  just  require  signalling
> Stewart> fragmentation  request/response, and  MAYBE some  defined behaviour
> Stewart> when  fragmentation  was  required  but not  available  during  the
> Stewart> lifetime of  a PW.  However it should  not be mandatory  to support
> Stewart> payload fragmentation.  
> 
> I agree.
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 26 Jul 2002 01:47:07 -0400

Luca and Eric,

Obviously I don't agree or I wouldn't have written the draft in the first 
place.  It's going to be a long time before we'll see a 9K MTU universally 
available, yet 9K frames are commonly used in ATM and GE networks, even 
more so than Frame Relay, although you certainly see them there as well.

Andy

-------

At 7/25/2002 03:10 PM -0600, Luca Martini wrote:
>In the past Small MTU networks might have been a problem , but today 
>almost all devices support some kind of enlarged MTU. ( thanks to MPLS 
>requirements )

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 30 Jul 2002 10:22:01 +0200

"Andrew G. Malis" wrote:
> place.  

I do agree with much of what Luca and Eric are saying and I helped write the
draft. 

> It's going to be a long time before we'll see a 9K MTU universally

My understanding of the motivations behind use of 9K jumbo frames is for a
fairly cheap performance increase for certain applications on a network which
can handle such large frames natively. I think that the cost justification for
jumbo frame usage is no longer true if you are paying the processing penalty to
fragment and reassemble these frames at aggregation points.

Fragmentation and reassembly to support mismatched and mismanaged MTUs should
only be used as a last resort. The ability to enable and disable support for
reassembly on one side of the PW and advertise this to a peer is a fundamental
requirement for this to be the case.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 30 Jul 2002 10:55:12 +0200

> uncommon; indeed, it might be quite common.

But it might be quite common just for a few, possibly very slow, links which
could be directed to a PE which has the ability to support reassembly, even if
doing so via a slow software path. 

> provided in fastpath, you might as well omit it.

I too see no advantage to requiring slowpath reassembly, but stop short of
thinking such a feature would be entirely useless. Expounding on my above
commment, one could have a lone handful of 56K FR CEs in a remote closet which
expect a large MTU with their current configuration and cannot be touched. The
vast majority of your traffic could be well-managed with reasonable MTUs for the
PWE3 service, while still being able to handle a small portion of your PWE3
traffic as a legacy service over your slowpath (with, perhaps, a higher
price-tag associated with such service).

Further, we have the well-noted ISIS Hello frames which may exhibit a pattern of
only a small number of packets requiring reassembly. 

Also, if 99% of the traffic running on your PW is IP, you can perform PMTU at
the PE for this traffic in hopes of controlling the MTU at the source, while
still allowing the 1% of non-ip traffic to be fragmented and reassembled. 

In all cases, the ability to turn off reassembly on any or all PWs should be
possible and the new effective MRU advertized to the other side of the PW link.

> arrived. 

Eric> Of course, it's still far from being free.

And that's the point. Whether the cost of managing MTUs in your network is more
expensive than the hardware necessary to support fragmentation and reassembly at
any time. I stand somewhere in the middle -- That one should *try* to manage the
MTUs in as many ways as possible, but when the burden is simply too excessive
(for a variety of reasons: operational, technical, political, historical, etc.)
one should at least be able to _resort_ to an interoperable fragmentation and
reassembly method understanding the cost involved.

> Stewart> payload fragmentation.

Same here, though I would say it should not be mandatory to support payload
*reassembly* - generally speaking, fragmentation is not nearly as much of a
burden.