Re: [PWE3] WGLC comments on: draft-ietf-pwe3-congcons-02.txt

"Black, David" <david.black@emc.com> Sun, 10 August 2014 02:34 UTC

Return-Path: <david.black@emc.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269E31A03FE for <pwe3@ietfa.amsl.com>; Sat, 9 Aug 2014 19:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level:
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, 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 P93fsuQWEP02 for <pwe3@ietfa.amsl.com>; Sat, 9 Aug 2014 19:34:13 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F3D1A03F8 for <pwe3@ietf.org>; Sat, 9 Aug 2014 19:34:12 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7A2YAoN018704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2014 22:34:11 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7A2YAoN018704
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1407638051; bh=X8Vy/7OtsPqDTMrKPNH2WCblbrM=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Co3vrC6i3ibNg+1uKlR5T4h22qtMebW+smhc4yZlJhnd6V9gqWX+0Jv1ShFeTLb81 YRHU8klY4W6ZzdFkbp8+V5J7/LSDBYyJgSamFuHdjjf8mseoxQhZ6K6YnjQbMkuvbr tXW/z5uYEFS+zebXhDN5C2YaOGrATeYSc7RWEjKg=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s7A2YAoN018704
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Sat, 9 Aug 2014 19:33:57 -0700
Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7A2Xu5E001855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 22:33:57 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Sat, 9 Aug 2014 22:33:55 -0400
From: "Black, David" <david.black@emc.com>
To: Yaakov Stein <yaakov_s@rad.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Date: Sat, 09 Aug 2014 22:32:24 -0400
Thread-Topic: WGLC comments on: draft-ietf-pwe3-congcons-02.txt
Thread-Index: Ac+zEP27iWho+8uAQLKBEFcFeq8EIgBLGLOA
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077B951928@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077B9517F4@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712077B9517F4@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/SeaP1ReCtxiSFDaJvfCtVV3a5Ig
Subject: Re: [PWE3] WGLC comments on: draft-ietf-pwe3-congcons-02.txt
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3/>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 02:34:16 -0000

Following up on this ...

> As we're now moving quickly to try to complete this draft , I agreed
> w/Yaakov that my author comments would be sent in as WG Last Call comments ...
> ... so here they are:

... with some suggested new text ...
 
> Major issues:
> 
> The reference to a transport circuit breaker in section 3 is a bit optimistic
> and high level:
> 
> 	We can accomplish this by
> 	employing a transport circuit breaker, by which we mean an automatic
> 	mechanism for terminating a flow to prevent negative impact on other
> 	flows and on the stability of the network
> 	[I-D.fairhurst-tsvwg-circuit-breaker].
> 
> This should be accompanied by at least an example of how to do this - past
> discussion has suggested carrier monitoring of delivered service quality
> in order to shut down PWs that are experiencing loss rates that result in
> unacceptable service quality (as defined for us by the ITU ...).  I'd also
> like to add some text to suggest that operators use this sort of circuit
> breaker practice when TDM PWs compete with elastic traffic.

After this text in Section 3:

   We can accomplish this by
   employing a transport circuit breaker, by which we mean an automatic
   mechanism for terminating a flow to prevent negative impact on other
   flows and on the stability of the network
   [I-D.fairhurst-tsvwg-circuit-breaker].  Note that a transport circuit
   breaker is intended as a protection mechanism of last resort, just as
   an electrical circuit breaker is only triggered when absolutely
   necessary.  

I suggest adding:

   For TDM pseudowires, such a circuit breaker can be realized via
   operator monitoring of drop rates and consequent on the quality of
   TDM service delivered and shutting down TDM pseudowires that persistently
   fail to deliver acceptable TDM service (as defined by [G775] and
   [G826]).  This document explains why a TDM PW that is causing congestion
   problems via interference with elastic traffic cannot be delivering
   acceptable TDM service (see the rest of this Section, plus Appendices
   A and B).

And breaking the paragraph after the added text.

> Figure 1 and Figure 2 indicate that based on using the TCP throughput
> equation as a proxy for potential impact on elastic traffic (which is what
> we're doing in this draft), for the same fixed bandwidth PW, a larger segment
> size is less likely to cause impacts.  I'd like to add a suggestion to use
> the larger PW segment sizes as long as they're consistent with delivery of
> the service.  There's been a related (long-to-the-point-of-ratholed) debate
> over in the Transport Area about whether packet-rate-limited/congestible
> forwarding is still relevant.  My view is that such equipment exists, and
> hence that this is a relevant consideration for this draft, and would not
> mention that issue here.

Ignoring the rathole invitation ;-).  This is still in section 3, after:

   We see that in general for large packet sizes, short delays, and low
   packet loss rates, the TDM pseudowires consume much less bandwidth
   than TCP would under identical conditions.  Only for small packets,
   long delays, and high packet loss ratios, do TDM PWs potentially
   consume more bandwidth, and even then only marginally.

I suggest adding:

   Comparing figures 1 and 2, use of a larger segment size for a T1 or E1
   TDM PW moves the operational behavior of the PW away from the boundary
   at which the TCP throughput equation suggests that undue interference with
   elastic traffic may start to occur.  We suggest that larger segment
   sizes be preferred for T1 and E1 TDM PWs, but note that other
   considerations may favor smaller segment sizes (e.g., jitter buffer
   size, bounding the impact of an isolated packet drop event).

and again, breaking the paragraph after that added text.

I hope that latter sentence ("We suggest that ...") is acceptable to the WG.

> Minor issues:
> 
> Section 2 is about Ethernet PWs that carry elastic traffic.  Should others
> be mentioned as also covered by this analysis - e.g., ATM and Frame Relay
> PWs carrying elastic traffic?

After:

   In this section we consider Ethernet PWs that primarily carry
   congestion-responsive traffic.  We show that we automatically obtain
   the desired congestion avoidance behavior, and that additional
   mechanisms are not needed.

I suggest adding:

   This discussion is applicable to any PW that carries congestion-
   responsive traffic (e.g., ATM and Frame Relay PWs); Ethernet PWs are
   used here for clarity, as they are a common example.
 
> Section 2 does not cover Ethernet PWs carrying inelastic traffic - that would
> be unusual, but should it be explicitly noted as out of scope, or just not
> discussed (as is the case for the current text)?

I suggest doing nothing here, and planning to deal with this concern
if it should arise later (e.g., IETF Last Call or IESG Evaluation).
 
> Section 3 should say that the reason the draft focuses on TDM PWs is that
> they're the inelastic PWs that are likely to be carried over IP in practice.
> My understanding is that other potentially inelastic PWs are MPLS-only
> in practice.

After:

   Inelastic PWs, such as TDM PWs ([RFC4553][RFC5086][RFC5087]), are
   potentially more problematic than the elastic PWs of the previous
   section.  Being constant bit-rate (CBR), TDM PWs can not be made
   responsive to congestion.  On the other hand, being CBR, they also do
   not attempt to capture additional bandwidth when neighboring TCP
   flows back off.

I suggest adding:

   We focus on TDM PWs here as they are the only inelastic PWs that are
   likely to be IP-encapsulated in practice.  Most other inelastic PWs
   tend to only be used with MPLS.

[I'd ask Yaakov and other PW experts to double-check the latter sentence,
please.]

> A terminology section to roll up all the acronym expansions (e.g., TDM, CBR)
> in one place seems like a good idea.

These four acronyms would be good to put into a terminology section:

CBR Constant Bit Rate
PSN Packet Switched Network
PW Pseudowire
TDM Time Division Multiplexing

> 
> This text on p.11 could be incendiary:
> 
> 	Under this condition it is safe to place the TDM PW along with
> 	congestion - responsive traffic such as TCP, without causing
> 	additional congestion.
> 
> First of all to reduce the flammability, "safe" -> "reasonable" and there
> are a number of other occurrences of "safe" that deserve similar treatment ;-
> ).
> Beyond that, this assertion is dependent on the operating conditions staying
> within that reasonable operating envelope, which entails use of something
> like a circuit breaker - I'd say that here, and reference the earlier
> circuit breaker discussion.

Global substitution: "safe" -> "reasonable", starting with the abstract.

Then for this specific text on p.11:

OLD
 	Under this condition it is safe to place the TDM PW along with
 	congestion - responsive traffic such as TCP, without causing
 	additional congestion.
NEW
	Under this condition it is reasonable to place the TDM PW in competition
      with congestion-responsive traffic such as TCP, as the result should not
      produce unacceptable congestion effects.  That assumes that the operating
      conditions remain within the reasonable operating envelope - as discussed
      above, a transport circuit breaker is a suggested means of managing a TDM
      PW so that it is shut down if operating conditions remain persistently
      outside the reasonable operating envelope for the PW (e.g., due to a
      high packet loss rate).

> Figures 7 and 8 could use some shading or lines to indicate the typical
> deployed operating regions for the pseudo-wires to visibly show that they
> fall under the curves, particularly for larger segment sizes.  I'd also
> repeat or refer to the suggestion to use larger
> 
> Nits:
> 
> References aren't allowed in abstracts, so remove reference to
> [I-D.fairhurst-tsvwg-circuit-breaker]
> 
> Introduction, first paragraph, delete "PWE3" towards end of paragraph -
> 
>    preferably the 4 byte PWE3 control word.
> 
> In addition to its current general statements, the Security Considerations
> section should point to the security considerations sections in a few
> particularly relevant RFCs - I'd suggest 3985, 4553, 5086 and 5087.

After:

   This document does not introduce any new congestion-specific
   mechanisms and thus does not introduce any new security
   considerations above those present for PWs in general.

I suggest adding a new paragraph:

   For PW security considerations, see the security considerations sections
   of the cited RFCS; the security considerations in [RFC3985], [RFC4553],
   [RFC5086] and [RFC5087] are particularly applicable to this document.

> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: pwe3 [mailto:pwe3-bounces@ietf.org] On Behalf Of Yaakov Stein
> > Sent: Thursday, July 24, 2014 4:52 PM
> > To: pwe3@ietf.org
> > Subject: Re: [PWE3] I-D Action: draft-ietf-pwe3-congcons-02.txt
> >
> > Please look at the PDF version only
> > (the txt version does not have the graphs).
> >
> > Y(J)S
> >
> >
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3