Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 11 December 2013 06:05 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0E1AE39F; Tue, 10 Dec 2013 22:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ArpOVN4fIcz; Tue, 10 Dec 2013 22:05:38 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA261AE39C; Tue, 10 Dec 2013 22:05:37 -0800 (PST)
Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 11 Dec 2013 06:05:30 +0000
Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0837.004; Wed, 11 Dec 2013 06:05:30 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "curtis@occnc.com" <curtis@occnc.com>
Thread-Topic: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment
Thread-Index: AQHO9jb+Sq0tCZZscUehMpHq+OAdtQ==
Date: Wed, 11 Dec 2013 06:05:29 +0000
Message-ID: <96907ab6f1ec48c1971db740f7845ff4@AM3PR03MB532.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [5.153.9.203]
x-forefront-prvs: 0057EE387C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(13464003)(377454003)(52604005)(51704005)(53754006)(81542001)(76786001)(81342001)(76576001)(4396001)(49866001)(33646001)(46102001)(74662001)(47446002)(85852003)(83072002)(31966008)(51856001)(76176001)(47976001)(47736001)(76796001)(50986001)(74502001)(74876001)(54356001)(76482001)(74316001)(74706001)(65816001)(87266001)(2656002)(80022001)(63696002)(87936001)(66066001)(74366001)(83322001)(19580405001)(85306002)(90146001)(19580395003)(69226001)(56776001)(80976001)(54316002)(79102001)(53806001)(59766001)(71446004)(81816001)(56816005)(77982001)(81686001)(427584002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; CLIP:5.153.9.203; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
Cc: "samante@apple.com" <samante@apple.com>, "kireeti@juniper.net" <kireeti@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, "pwe3 (pwe3@ietf.org)" <pwe3@ietf.org>
Subject: Re: [mpls] [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:05:42 -0000

Curtis,
Lots of thanks for sending out the new text.

I still have a couple of issues with this version of the text: one technical and one editorial.

The technical issue is about the fragment "A small jitter buffer is always necessary". 

I am not sure this is correct, since I am aware of several PW implementations that pass the payload of a received PW packet directly for transmission via the corresdponding attachment circuit. Of course this payload would be stored in some Tx queue associated with the attachment circuit and controlled by the appropriate egress scheduler, but IMO this does not constitue a PW jitter bufer, since the PW interworking function does not exersize any control over these queues.
In particular, these queues could not be used for re-ordering misordered PW packets.
IMHO and FWIW this understanding matches RFC 3985 which mentions (in Section 5.2.1.1 "Frame Ordering") that reodering as the strategy for handling mis-ordered packets introduces additional delay (i.e., requires a ddicated jitter buffer), while the alternative strategy of discarding mis-ordered packets does not introduce such additional delay.

The editorial issue is about the entire sentence that contains the above-mentioned fragment, i.e., "A small jitter buffer is always necessary and the jitter buffer is needed regardless of whether reordering is done" - to me this looks like an unnecessary repetition if if it were techically correct.

Hence I would like to suggest discrading the problematic sentence as the simplest way to resolve both issues.

Hopefully these notes will e helpful.

Regards,
     Sasha


________________________________________
From: Curtis Villamizar <curtis@occnc.com>
Sent: Tuesday, December 10, 2013 5:47 PM
To: Alexander Vainshtein
Cc: curtis@ipv6.occnc.com; curtis@occnc.com; kireeti@juniper.net; samante@apple.com; agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)
Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-forwarding: a minor comment

In message <F9336571731ADE42A5397FC831CEAA025AC56C9D@ILPTWPVEXMB02.ecitele.com>
Alexander Vainshtein writes:
>
> Curtis,
>
> Lots of thanks for a prompt and very detailed response.
> May I suggest an alternative version of the following text fragment?
>
> <Curtis>
> >   Identifying the position of any lost packets is important
> >    for PW services which are attempting to reconstruct a bit stream
> >    which maintains bit timing, such as time division multiplexing (TDM)
> >    services.  TDM and other PW services which require strict ordering
> >    also require that misordered packets be either dropped or reordered.

Invalid XML - you didn't close this element.  :-)

>  <Sasha>
>
>    Identifying lost PW packets and exact amount of lost payload is
>    critical for PW services which maintain bit timing, such as Time
>    Division Multiplexing (TDM) services since these services MUST
>    compensate lost payload on a bit-for-bit basis.
>
>    With these services PW packets that have been received out of order
>    also MUST also be identified and may be either re-ordered or
>    dropped.  Reordering requires, in addition to sequence numbering, a
>    "de-jitter buffer" in the egress PE, and ability to reorder is
>    limited by the depth of this buffer. The down side of maintaining a
>    de-jitter buffer is added end-to-end service delay.
>
>   </Sasha>

Accepted with a small change.

After the words "down side"
s/de-jitter buffer/large jitter buffer/
Elsewhere
s/de-jitter buffer/jitter buffer/g
Then add the sentence.

   A small jitter buffer is always necessary and the jitter buffer
   is needed regardless of whether reordering is done.

This yields a slightly changed second paragraph.

   With these services PW packets that have been received out of order
   also MUST also be identified and may be either re-ordered or
   dropped.  Reordering requires, in addition to sequence numbering, a
   "jitter buffer" in the egress PE, and ability to reorder is limited
   by the depth of this buffer. The down side of maintaining a large
   jitter buffer is added end-to-end service delay.  A small jitter
   buffer is always necessary and the jitter buffer is needed
   regardless of whether reordering is done.

Is this wording OK with you?

Curtis

> Hopefully this will be useful.
>
>
> Regards,
>      Sasha
>
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@ipv6.occnc.com]
> > Sent: Monday, November 25, 2013 8:30 PM
> > To: Alexander Vainshtein
> > Cc: curtis@occnc.com; kireeti@juniper.net; samante@apple.com;
> > agmalis@gmail.com; cpignata@cisco.com; mpls@ietf.org; Yaakov Stein
> > (yaakov_s@rad.com); pwe3 (pwe3@ietf.org)
> > Subject: Re: [PWE3] Pseudowire Sequence Number in draft-ietf-mpls-
> > forwarding: a minor comment
> >
> >
> > In message
> > <F9336571731ADE42A5397FC831CEAA025392F92F@ILPTWPVEXMB01.ecitele.c
> > om>
> > Alexander Vainshtein writes:
> > >
> > > Hi all,
> > >
> > > I would like to comment on the text in Section 2.1.8.1 "Pseudowire
> > > Sequence Number" in draft-ietf-mpls-forwarding-03 - MPLS Forwarding
> > > Compliance and Performance Requirements
> > > <http://tools.ietf.org/html/draft-ietf-mpls-forwarding-03>.
> > >
> > > This section states, in short, that the main drive for using the
> > > sequence number in the PW Control Word is handling of packet
> > > reordering events. TDM PWs are presented as a major example, with CBR
> > > ATM services as another example.
> > >
> > > In fact, this statement is not accurate.
> >
> > Yes.  You are correct in pointing this out as inaccurate by omitting
> > the other important function of identifying drops for the purpose of
> > recunstructing TDM bit streams.
> >
> > Andy brought up resequencing being a strong provider request.
> > Reordering is far more common than loss particularly for high priority
> > services on provider networks and without resequencing reorder results
> > in PW loss in what could otherwise be lossless service.
> >
> > So we should get the base requirements right but still reflect this,
> > but strictly as advice with no normative wording.  We had used the
> > phrase "is beneficial" and will retain that.
> >
> > Andy brought up the topic.  The incorrect wording in the existing
> > draft is my fault.  This text went in fairly early with a lot of other
> > changes and it appears that no one had since given it a careful enough
> > read and review until you came along.
> >
> > > The main drive for mandating the use of sequence number in TM PWs is
> > > the need to detect and count lost packets because the egress PE MUST
> > > compensate the lost payload bit for bit.
> > >
> > > Ability to compensate reordering of PW packets at egress is a side
> > > effect of (a) sequence number usage and (b) usage of the de-jitter
> > > buffer in the egress PW. It is not mandatory and in any case is
> > > limited by the depth of the de-jitter buffer: re-ordered packets that
> > > cannot be accommodated within this buffer are treated as lost.
> > >
> > > Additional details can be found, e.g., in section 6.2.2 of RFC
> > > 4553<http://tools.ietf.org/html/rfc4553>. Ability to re-order
> > > mis-ordered PW packets is defined there as OPTIONAL, while replacement
> > > of the payload of lost PW packets is defined as MANDATORY.
> >
> > The change below at the top of the section more accurately reflects
> > requirements in the RFCs but still states that resequencing can be
> > beneficial.  The comments about EPD and PPD are dropped and therefore
> > also the informative reference.
> >
> >  Context:
> >
> >  2.1.8.1.  Pseudowire Sequence Number
> >
> >  OLD
> >
> >    Pseudowire (PW) sequence number support is most important for PW
> >    payload types with a high expectation of in-order delivery.
> >    Resequencing support, rather than dropping at egress on out of order
> >    arrival, is most important for PW payload types with a high
> >    expectation of lossless delivery.  For example, TDM payloads require
> >    sequence number support and require resequencing support.  The same
> >    is true of ATM CBR service.  ATM VBR or ABR may have somewhat relaxed
> >    requirements, but generally require ATM Early Packet Discard (EPD) or
> >    ATM Partial Packet Discard (PPD) [ATM-EPD-and-PPD].  Though sequence
> >    number support and resequencing support are beneficial to PW packet
> >    oriented payloads such as FR and Ethernet, they are highly desirable
> >    but not as strongly required.
> >
> > NEW
> >
> >    Pseudowire (PW) sequence number support is most important for PW
> >    payload types with a high expectation of lossless and/or in-order
> >    delivery.  Identifying the position of any lost packets is important
> >    for PW services which are attempting to reconstruct a bit stream
> >    which maintains bit timing, such as time division multiplexing (TDM)
> >    services.  TDM and other PW services which require strict ordering
> >    also require that misordered packets be either dropped or reordered.
> >
> >    PW services which are not timing critical bit streams in nature are
> >    cell oriented or frame oriented.  Though resequencing support is
> >    beneficial to PW cell and frame oriented payloads such as ATM, FR and
> >    Ethernet, they are highly desirable but not required.
> >
> > NEW (end of subsection after list of possible reording causes)
> >
> >    In provider networks which use multipath techniques and which may
> >    occassionally rebalance traffic or which may change PW paths
> >    occasionally for other reasons, reordering may be far more common
> >    than loss.  Where reordering is more common than loss, resequencing
> >    packets is beneficial, rather than dropping packets at egress when
> >    out of order arrival occus.  Resequencing is most important for PW
> >    payload types with a high expectation of lossless delivery since in
> >    such cases out of order delivery within the network results in PW
> >    loss.
> >
> > The final paragraph sums up the motivation for highlighting
> > resequencing as beneficial and desirable.  It does so without any
> > normative wording.
> >
> > > Hopefully these notes will be useful.
> > >
> > > Regards,
> > >      Sasha
> >
> > These notes are very useful.  Thank you.
> >
> > Please let us know if you (and the WG) are OK with the rewording
> > proposed above.
> >
> > Curtis