Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-04.txt

From: [email-masked]
Date: Tue, 04 Nov 2003 15:27:23 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Metrics Working Group of the IETF.

	Title		: Packet Reordering Metric for IPPM
	Author(s)	: A. Morton
	Filename	: draft-ietf-ippm-reordering-04.txt
	Pages		: 25
	Date		: 2003-11-4
	
This memo defines a simple metric to determine if a network has
maintained packet order. It provides motivations for the new metric,
gives the metric definition, and discusses the issues associated
with its measurement. The memo defines additional sample metrics to
quantify the extent of reordering in several useful dimensions. Some
examples of evaluation using the various sample metrics are
included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ippm-reordering-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ippm-reordering-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Al Morton <[email-masked]>
Date: Wed, 05 Nov 2003 16:40:49 -0500

At 03:27 PM 11/04/2003 -0500, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts...

We finally got this announced and posted, it was more fun than usual.
Thanks to our Chairs for their help.

One of the Action Items from the last meeting was to prepare
some text on fragmentation.  I put this together as an Appendix,
because it's two pages long and would interrupt the flow.
I also held it out of the 04 version, seeking simplifications
over time but with minimal success.  Suggestions welcome.

Al

13. Appendix on fragment order evaluation

    Section 3 stated that fragment re-assembly is assumed prior to order
    evaluation, but that similar procedures could be applied prior to
    re-assembly.  This appendix gives definitions and procedures to
    identify reordering in a packet stream that includes fragmentation.

    The Metric retains the same name, Type-P-reordered, but additional
    parameters are required.

13.1 Additional Metric Parameters:

    +  MoreFrag, the state of the More Fragments Flag in the IP header

    +  FragOffset, the offset from the beginning of a fragmented packet,
      in 8 octet units (also from the IP header).

    +  FragSeq#, the sequence number from the IP header of a fragmented
      packet currently under evaluation for reordering. When set to
      zero, fragment evaluation is not in progress.

    +  NextExpFrag, the Next Expected Fragment Offset at the
      Destination, in 8 octet units. Set to zero when fragment evaluation
      is not in progress.

    The packet sequence number, s, is assumed to be the same as the IP
    header sequence number. Also, the value of NextExp does not change
    with the in-order arrival of fragments. NextExp is only updated when
    a last fragment or a complete packet arrives.

    Note that packets with missing fragments MUST be declared lost, and
    the Reordering status of any fragments that do arrive MUST be
    excluded from sample metrics.

13.2 Definition:

    The value of Type-P-Reordered is typically false (the packet is in-
    order) when

    * the sequence number s >= NextExp,

    * AND the fragment offset FragOffset >= NextExpFrag

    However, it more efficient to define reordered conditions exactly,
    and designate Type-P-Reordered as False otherwise.

    The value of Type-P-Reordered is defined as True (the packet is
    reordered) under the conditions below. In these cases, the NextExp
    value does not change.

    Case 1: if s < NextExp

    Case 2: if s>= NextExp AND s < FragSeq#

    Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag

    This definition can also be illustrated in pseudo-code. An early
    draft version of the code follows, and simplification may be
    possible. The challenging aspect surrounds the housekeeping for the
    new parameters.

    NextExp=0;
    NextExpFrag=0;
    FragSeq#=0;

    while(packets arrive with s, MoreFrag, FragOffset)
    {
    if (s>=NextExp AND MoreFrag==0){
         /* a normal packet or the last fragment of a packet arrived */
         NextExp = s+1;
         FragSeq# = 0;
         NextExpFrag = 0;
         Reordering = False;
         }
    if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){
         /* a fragment of a new packet arrived, possibly with a
         higher sequence number than the current fragmented packet */
         FragSeq# = s;
         NextExpFrag = FragOffset+1;
         Reordering = False;
         }
    if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){
         /* a fragment of the "current packet s" arrived */
         if (FragOffset >= NextExpFrag){
                 NextExpFrag = FragOffset+1;
                 Reordering = False;
                 }
         else{
                 Reordering = True; /* fragment reordered  */
                 }
         }
    if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){
         /* case where a late fragment arrived */
         Reordering = True;
         }
    else { /* when s < NextExp */
         Reordering = True;
         }
    }

    A working version of the code would include a check to ensure that
    all fragments of a packet arrive before using the Reordered status
    further, such as in sample metrics.

13.3 Notes on Sample Metrics

    All fragments with the same Source Sequence Number are assigned the
    same Source Time.

    Evaluation with byte stream numbering may be simplified if the
    fragment offset is simply added to the SourceByte of the first
    packet (with fragment offset = 0), keeping the 8 octet units of
    the offset in mind.

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Wed, 05 Nov 2003 16:40:49 -0500

Al

13.2 Definition:

    Case 1: if s < NextExp

    NextExp=0;
    NextExpFrag=0;
    FragSeq#=0;