Subject: Re: issue with frame fragmentation

From: George Wilkie <[email-masked]>
Date: Wed, 17 Apr 2002 19:05:26 +0100 (BST)

I think the last point needs to be answered first.
Are we looking for a general fragmentation scheme which is used for all
attachment circuit types: FR, ethernet, hdlc, etc,
or a FR specific fragmentation scheme?

If it is the former, which the last point implies, then why is it part of
the FR draft? - shouldn't it be part of a common document?
For IP PSN, IP fragmentation could be a candidate for this functionality.

If it is the latter, architecturally it is outside the PW and
attachment circuit specific so should take place in the "NSP" rather
than the PW.

Cheers.

On Wed, 17 Apr 2002, Claude Kawa wrote:

> We need a separate thread on this one it is a general issue.
>
>
> The protocol issue about frame fragmentation is whether we put the
> fragmentation indicators (bits I and L) in the FRoPW header as in draft
> kamapabhava figure 3 shown below:
>
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Res |P|B|F|D|C|I|L|  Length   | Sequence Number               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                  Figure 3 - FRoPW header structure
>
> or in the payload packet field as in Figure 2 shown below and use FRF.12 (on
> frame relay fragmentation) to do the fragmentation by a PE:
>
>        +-------------------------------+
>        |                               |
>        |       Delivery Header         |
>        |                               |
>        +-------------------------------+
>        |                               |
>        |       FRoPW Header            |
>        |                               |
>        +-------------------------------+
>        |                               |
>        |       Payload packet          |
>        |                               |
>        +-------------------------------+
>
>      Figure 2 - General format of FRoPW packet
>
> One question asked (by Danny) was if there is a compelling reason NOT to use
> FRF.12. Here is my initial analysis:
>
> FRF.12 requires that we configure a device to determine whether FRF.12 is
> supported or not. FRF.12 is either supported per port or not. If it is
> supported the first few bytes of the payload have to be processed because
> they contain the fragmentation header. A context look-up has to be performed
> by a device (a PE in our case) to determine whether to look into the payload
> or not. This clearly slows the processing.
>
> With the fragmentation encoding as proposed in kamapabhava, the control
> information about fragmentation is in the PW header. This results in faster
> operation.
>
> Secondly FRF.12 requires to use a sequence number field to ensure that the
> receiver got all the fragments to re-assemble them properly. We already have
> a sequence number field in the FRoPW header. This use of fragmentation based
> on FRF.12 results in additional protocol design and implementation
> inefficiencies.
>
> The fragmentation proposed for frame relay is general enough. It is
> applicable to other frame based technologies such as Ethernet over PW. It
> makes more sense to put the fragmentation control information in the PW
> header.
>
>
> Claude Kawa
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Apr 2002 19:41:17 +0100

Are you planning to map FRF12 fragmentation onto PWE3 
fragmentation, or are you planning to mandate that FRF 
fragmented packets cannot be transported?

If you are planning to carry them, then a mapping function
needs to be specified, as well as a methof of refragmenting
fragments.

If we carry the full FR header we do not have to worry 
about how to carry pre-fragmented packets. If we need to 
fragment in the  PE, running FRF.12 in the NSP means that 
we do not have to define the fragmentation operation in PWE3.
Isn't this simpler and more general?

> Claude Kawa wrote:
> The protocol issue about frame fragmentation is whether we put the fragmentation indicators (bits
> I and L) in the FRoPW header as in draft kamapabhava figure 3 shown below:
> 
>  0                   1                   2                   3
> or in the payload packet field as in Figure 2 shown below and use FRF.12 (on frame relay
> fragmentation) to do the fragmentation by a PE:
> 
> One question asked (by Danny) was if there is a compelling reason NOT to use FRF.12. Here is my
> initial analysis:
> 
> FRF.12 requires that we configure a device to determine whether FRF.12 is supported or not. FRF.12
> is either supported per port or not. If it is supported the first few bytes of the payload have to
> be processed because they contain the fragmentation header. 
> A context look-up has to be performed
> by a device (a PE in our case) to determine whether to look into the payload or not. This clearly
> slows the processing.

You have to do this anyway, because you are going to have to check whether the 
underlying frame has already been FRF.12 interface fragmented, and then to map all 
the bits.

> 
> With the fragmentation encoding as proposed in kamapabhava, the control information about
> fragmentation is in the PW header. This results in faster operation.

This is only a one bit lookup. Bit 1 of the first octet says whether the 
frame is fragmented, and on encapsulation you have to do this anyway. 

> 
> Secondly FRF.12 requires to use a sequence number field to ensure that the receiver got all the
> fragments to re-assemble them properly. We already have a sequence number field in the FRoPW
> header. This use of fragmentation based on FRF.12 results in additional protocol design and
> implementation inefficiencies.

On the contrart, its well defined in FRF.12 and out of scope in PWE3. You have to make the
check or mandate unpredictable behaviour if the user sends FRF12 traffic to you.

> 
> The fragmentation proposed for frame relay is general enough. It is applicable to other frame
> based technologies such as Ethernet over PW. It makes more sense to put the fragmentation control
> information in the PW header.

If we have to have a fragmenation scheme, agreed this is a generic one. I am not
convinced that you need to have one within the PWE3 context.

> Claude Kawa

Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 17 Apr 2002 19:05:13 -0400

Stewart,

This fragmentation is ONLY to get across the PW.  It is completely separate 
from end-to-end FRF.12 that may be contained in the frames.  Any 
pre-existing FRF.12 fragmentation is just data to the PW, just like any 
other FR frame.  You don't need to do anything special at all.

The main issue to me is whether you need two bits or six octets when 
fragmenting long FR frames to go across the PW, since FR frames are 
commonly as long as 4K octets and sometimes up to 8K octets.  Don't know 
many IP networks with an MTU that large.

Cheers,
Andy

--------

At 4/17/2002 07:41 PM +0100, Stewart Bryant wrote:

> fragmentation indicators (bits
> information about
> applicable to other frame
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Apr 2002 11:53:32 +0100

> other FR frame.  You don't need to do anything special at all.

Only for an end-end fragmented frame. What do you do if we get an interface 
fragmented frame? This places the fragmentation hearder BEFORE the frame 
relay header. Any spec that uses an intermediate format must describe the 
problem and either declare it as an unsupported type, or describe how to map it.

> commonly as long as 4K octets and sometimes up to 8K octets.  

This is misleading. The last time I looked at network packet statistics
the average packet size was way below 8K, and the two bytes of fragmentation
overhead is only needed on those long packets. The bandwidth saving
is therefore trivial.

On the other hand the complexity saving of just considering the PW a wire
and using existing payload specs to define how to process the payload
is great.

> Don't know

Don't know many packets that large either.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Apr 2002 07:50:36 -0400

Stewart,

>problem and either declare it as an unsupported type, or describe how to 

Interface fragmentation is just that - strictly local to the UNI or NNI 
interface.  If it is being used, then it must be reassembled before the 
frames are submitted to the PW, and perhaps re-fragmented using the 
end-to-end format (if you're using FRF.12) or by using the two bits in the 
headers, depending on the MTU of the PW.  The purpose of interface 
fragmentation isn't to solve MTU problems, since it is strictly local to a 
DTE-DCE or DCE-DCE interface; rather, it is to allow the use of real-time 
frames (such as FRF.11) on a relatively slow physical interface without the 
real-time frames having to wait for very long frames to completely clock 
out on the line.

So if you are using interface fragmentation, the process in the PE would be:

1. Clock in frames on the FR interface.

2. If the frames are interface-local fragments, then reassemble the 
complete FR frames.

3. Hand off complete FR frames to PW process.

4. If the frames are larger than the PW MTU, either:

4a. Drop them (Martini behavior)

4b. Fragment them and transmit them across the PW.

So we're discussing is how to do 4b - use end-to-end FRF.12, or use two 
bits in the PW header along with the existing sequence number for 
equivalent functionality, while saving on the FRF.12 header size (6 or 8 
octets, depending on the NLPID size).

>overhead is only needed on those long packets. The bandwidth saving

It's 6 or 8 octets, not 2, but I do agree that it's not huge.

>and using existing payload specs to define how to process the payload

Well, I already discussed that point in my message to Sasha.  I can't say I 
agree.

>Don't know many packets that large either.

In my Cascade experience, we had a good number of customers with networks 
carrying very long frames.  IP isn't the only FR application.

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Apr 2002 13:30:08 +0100

"Andrew G. Malis" wrote:
> frames are submitted to the PW, 

Now there is a core issue here. What is a pseudo wire? Is it

a) An method of implementing a pt-pt circuit with some degree of
(specified) correctness.

or is it

b) Some to be defined data munger feeding a wire, followed by a further
munger.

No wire that I am familiar with is capable of re-fragmenting anything.

What I am proposing is that we seperate the wire and the munger (called
an NSP function in the architecture), to simplify the problem.

> and perhaps re-fragmented using the

Firstly, is there anthing in the space that excludes its use to solve
the MTU problem.

Secondly, the spec needs to either explicitly declare a method of supporting
this, or explicitly declare it not supported.

> 2. If the frames are interface-local fragments, then reassemble the

That does not sound very wirelike behaviour to me.

> carrying very long frames.  IP isn't the only FR application.

Please provide the packet length distribution data so that we can calculate 
the overhead in each case.

BTW what was the application, and how common is that now?

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 10:51:59 -0400

I'd like to get some clarification first on just what the semantics would be
for fragmentation/reassembly. 

We might  decide, for  example, that  we would only  do reassembly  when the
fragments arrive  in order; failure of  a fragment to arrive  in order would
then cause  the entire frame to be  dropped.  If it is  possible to transmit
in-order  fragments as  they arrive  (i.e.,  without waiting  for the  final
fragment), this  can be a  relatively low cost and  straightforward process,
though it requires an "abort  this frame" function if a non-initial fragment
fails to arrive in order. 

This might make sense only on sequenced PWs. 

Is this what is envisioned?   (IMHO, anything more elaborate is probably not
feasible in the PEs.) 

Note, by  the way,  that IP fragmentation/reassembly  does not  provide this
semantics.  If one uses  IP fragmentation/reassembly, then missing fragments
need to  be timed out, and out  of sequence fragments will  likely result in
out of sequence frames being passed up, only to be discarded.  

If this  is the intended semantics, then  I think that Claude  and Andy have
made a reasonable case for a  PW-layer mechanism, though if such a mechanism
is adopted it probably shouldn't be service-specific. 

A better solution might be to figure  out what the MTU is, and to figure out
a way  of forcing the CEs  to do any necessary  fragmentation using service-
specific techniques.  Then the PEs don't have to do fragmentation/reassembly
at all.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Apr 2002 11:14:34 -0400

Eric,

Thanks for adding to the discussion.  Your last comment would be optimal if 
all FR end systems implemented FRF.12.  Sadly, this is not the case and 
thus the PE must compensate for small-MTU paths.

I had originally envisioned just reassembling the fragments in order (and 
dropping frames with missing/late fragments), but Sasha has made a good 
point that whether or not to reorder (rather than drop) in the receiver is 
really a local decision that doesn't affect interoperability, and thus the 
spec doesn't have to mandate it one way or the other.  That could apply 
both to the receipt of fragments and to entire frames.

Cheers,
Andy

--------

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Apr 2002 11:31:50 -0400

Stewart,

>an NSP function in the architecture), to simplify the problem.

I fully agree.  But there's no reason why you can't view reassembly as 
"above" the PW functionality, even if it is using bits in the same header 
for transmission efficiency.

> > The purpose of interface

See my previous email to Sasha to answer your first question.

On your second point, FRF.12 already requires that interface fragmentation 
be terminated before the frames can enter a FR network.  That would include 
a FR PW.  But we could also mention that in the PWE3 draft as well.

>That does not sound very wirelike behaviour to me.

Again, this is something you NEED to do (by FRF.12) if you are implementing 
FRF.12 interface fragmentation.  FRF.12 interface fragmentation is not 
required (it's a local decision by a service provider whether or offer it 
as a service or not), so if you don't want it in your PE, just don't 
implement it.

Cheers,
Andy