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

"Black, David" <david.black@emc.com> Mon, 18 August 2014 12:45 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 D2B1A1A01D2 for <pwe3@ietfa.amsl.com>; Mon, 18 Aug 2014 05:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.268
X-Spam-Level:
X-Spam-Status: No, score=-5.268 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, GB_I_LETTER=-2, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ayWfkdSZgTwj for <pwe3@ietfa.amsl.com>; Mon, 18 Aug 2014 05:45:01 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDC41A01BD for <pwe3@ietf.org>; Mon, 18 Aug 2014 05:45:00 -0700 (PDT)
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7ICirDe031998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Aug 2014 08:44:54 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7ICirDe031998
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1408365894; bh=v8gUVV4RslESWP6Bvp29SAiJGZ0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=mifgFUtvIcWdlKZU4InQ/Lygaa0EJe21wwJYi2w+wQ7h+vjmIomsE3lQ5dToAR8T5 QgFUERG8pe9826ZlgEDXqBgbsL63bHbn98ne80WUxqhlm7D7RcXKxln2LqyAVLef0a kEqsX5tC3kC2rI66nMNyFtzNoasd/352OjVHE1Dk=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s7ICirDe031998
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 18 Aug 2014 08:44:40 -0400
Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s7ICieFU028082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 08:44:40 -0400
Received: from mx15a.corp.emc.com ([169.254.1.175]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Mon, 18 Aug 2014 08:44:40 -0400
From: "Black, David" <david.black@emc.com>
To: Bob Briscoe <bob.briscoe@bt.com>
Date: Mon, 18 Aug 2014 08:44:39 -0400
Thread-Topic: [PWE3] FW: WGLC comments on: draft-ietf-pwe3-congcons-02.txt
Thread-Index: Ac+4cK08ao1hnXAQQ/2ogxRmGCvqXACbcseg
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712077BB42180@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712077B9517F4@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077B951928@MX15A.corp.emc.com> <CAA=duU1E=4iQ6-DDccqk8HrcdLq1rQrfNq7Wkdoaq1=Kb6RX6A@mail.gmail.com> <CAA=duU1P0mEH3HLjzox3jNC1aSpsK4fcxg4nxpps+JoPOVLgGA@mail.gmail.com> <CAA=duU2g1mM+V2ebwXduZ1gDkaFYALywvsT+MmXZy465Lp+_Bw@mail.gmail.com> <cd5585641947490b878d2ac71cb32fb1@exrad6.ad.rad.co.il> <201408141302.s7ED2km0032238@bagheera.jungle.bt.co.uk> <8D3D17ACE214DC429325B2B98F3AE712077B952113@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712077B95212C@MX15A.corp.emc.com> <201408151006.s7FA6nWG003570@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408151006.s7FA6nWG003570@bagheera.jungle.bt.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077BB42180MX15Acorpemcc_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: DLM_1, public, GIS Solicitation
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/lX_Yu3j1a3HJ9bzB5anWKuNeyCU
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] FW: 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: Mon, 18 Aug 2014 12:45:13 -0000

Bob,

1-4 & 6: ok

5: "acceptable" is a good replacement for S-A-F-E, but I'm not sure about "friendly".  The key concept here is assurance that there are no problems.  How about "clearly acceptable"?  That may need some additional text to say that acceptable network and service behavior may be delivered outside the clearly acceptable region, but one cannot rely on the analysis in this draft (based on the TCP throughput formula) to reach such a conclusion.

7: I disagree - the tsvwg circuit breaker draft is rather general, and we now have two WG LC comments on this draft asking how to apply a circuit breaker to PWs.  I think we're on solid ground with the references to the ITU-T service quality standards and expecting operator monitoring of service quality.  OTOH, the word "persistently" seemed to be a concern, and I have no problem removing it (anyone who asks about that can be directed to G.775 and G.826).  New suggested text:

   For TDM pseudowires, such a circuit breaker can be realized via
   operator monitoring of drop rates and the quality of
   TDM service delivered in order to shut down TDM pseudowires that
   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 is also not delivering
   acceptable TDM service (see the rest of this Section, plus Appendices
   A and B).

8: I believe that figures 1 and 2 suffice to make the point, but I see that a recommendation may be a bit of a reach for this draft.  How about the following modified form of my first sentence, which just states the inference that can be drawn from Figures 1 and 2? -

   Figures 1 and 2 indicate that 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.

Thanks,
--David

From: Bob Briscoe [mailto:bob.briscoe@bt.com]
Sent: Friday, August 15, 2014 6:03 AM
To: Black, David
Cc: pwe3@ietf.org
Subject: Re: [PWE3] FW: WGLC comments on: draft-ietf-pwe3-congcons-02.txt

David,

I decided to think on a better word for 'safe' overnight, and allow others to comment. But no-one has, so here's my responses to all your outstanding points...

I've provided slightly updated xml source of my suggested edits (and a diff) here:
< http://www.bobbriscoe.net/projects/2020comms/pwe3-congcons/draft-ietf-pwe3-congcons-DIFF03b-02.html >
< http://www.bobbriscoe.net/projects/2020comms/pwe3-congcons/draft-ietf-pwe3-congcons-03b.txt >
< http://www.bobbriscoe.net/projects/2020comms/pwe3-congcons/draft-ietf-pwe3-congcons-03b.xml >
Again note: xml is purely for precision, not implying I have taken over editorship.

1. Happy with your new scoping text, except the the first 'independent' clangs with the second, and it's unnecessary anyway:
"  The concern is over PWs that share network capacity with elastic or congestion-responsive traffic, [independent of] whether that sharing is a result of the service provider network's traffic engineering and capacity planning or independent deployment of PWs by entities other than network operators.
"

2. My point wasn't to remove the reference to the 125us (in my suggested text I didn't). It was that the 125us stuff /alone/ doesn't warrant the 'thus' in the next clause; the logic needs to be connected by talking about the sum of the flight time /and/ the per-node processing time.
CURRENT:
   The one-way delay
   of a native TDM service consists of the physical time-of-flight plus
   125 microseconds for each TDM switch traversed; and is thus very
   small as compared to typical PSN network-crossing latencies.
SUGGESTED:
   The one-way delay
   of a native TDM service consists of the physical time-of-flight plus
   125 microseconds for each TDM switch traversed; so the total one-way delay for most TDM PWs has to be small compared to typical PSN network-crossing latencies.

5. I understand and agree - 'S-A-F-E region' is incendiary. But I don't like 'reasonable region' - it's slightly /too/ meaningless.

Other possibilities are:
- admissable region (problem: implies outside the region is inadmissable)
- harmonious region (problem: too Californian)
So I suggest two words:
- friendly or acceptable, each used depending on context.

On the graphs, I suggest 'operating region (friendly under curve)' because that is precisely where the curves come from - 'friendly' does what it says on the tin, and the implied 'unfriendly' above the curve correctly avoids implying that the sky will fall.

Elsewhere, I suggest the following replacements for the S-word:
"It is thus worthwhile specifying under what conditions such competition is acceptable"
"One may view this condition as defining a 'friendly' operating envelope for a TDM PW"
"Under this condition it is acceptable to place the TDM PW along with ... TCP. "
"comparison with something widely considered to offer an acceptable response to congestion"


7. Circuit breaker
Scope creep. Rat-hole. Stop digging.
Yes, I know Stewart has asked us to dig out another rat as well, but the appropriate response is "Out of scope".

You might think your text is uncontroversial, but if we are tempted to take Stewart's bait (rat metaphor intended), it will probably start new debates that this doc doesn't deserve: "What does persistent mean?", "Which traffic is more important/ valuable?", yada yada.

I suggest the text merely makes it clear that this debate is in scope for elsewhere, not here. I've also just realised that Yaakov has written the sentences around circuit breaker with the wrong logical sequence. The circuit breaker needs to be introduced as something the PW uses when its /own/ quality has failed, which should avoid any need to shut down because it is threatening elastic services:

CURRENT:
      If the bandwidth consumed by a TDM PW is
      considered detrimental, the only available remedy is to completely
      shut down the PW, by using a transport circuit breaker mechanism.
      However, we will show that even before such an action is
      warranted, the PW will become unable to faithfully emulate the
      native TDM service; for example, when a TDM service is carrying
      voice grade telephony channels, the voice quality will degrade to
      below useful levels.
SUGGESTED:
      We will show that, before a PW becomes deterimental to elastic traffic, it will become unable to faithfully emulate the
      native TDM service; for example, when a TDM service is carrying
      voice grade telephony channels, the voice quality will degrade to
      below useful levels. Once the quality of the emulated service is persistently unacceptable, if a PW shuts down selected flows or shuts itself down completely, it will automatically avoid detriment to elastic traffic. A transport circuit breaker [I-D.fairhurst-tsvwg-circuit-breaker] could be used, but mechanism is beyond the scope of the present document.


8. Segment size.
Everyone's in a big group-hug because we've written a draft showing there's is no need to change anything. Then just at the end of an uneventful WGLC, we hear David's voice from the bottom of a deep hole shouting, "avoid the rat-hole invitation", while furiously digging for a rat.

There is no need to add a recommendation that PWs need to be changed to use larger packets. No matter how hedged and soft this recommendation would be, it's not needed anyway. Stop digging.

Yaakov's new text is fine as it stands. "Only for small packets, long delays, and high packet loss ratios, do TDM PWs potentially consume more bandwidth, and even then only marginally. "

In order to justify your sentence, we would have to include graphs with packet-rate (not bit-rate) on the vertical axis and go into a whole treatise as to why packet-rate comparison might be important as well. Then the graph would show one plot for all TCP segment sizes and multiple plots for PWs with different packet sizes. Then we'd see that the corner of the two smallest packet PWs just clipped the TCP curve at loss probabilities that are stupidly large anyway. So even after all this, it would hardly justify a need for your sentence.

All that digging would not be worth it, just to discover (again) that there is no rat.


Bob


At 19:39 14/08/2014, Black, David wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
         boundary="_000_8D3D17ACE214DC429325B2B98F3AE712077B95212CMX15Acorpemcc_"

And forwarding my views to the list ...

... On Bob's six thoughts (I have problems with 2 & 5 - the other 4 are basically ok w/me) plus follow-ups on Bob's concerns w/my two major issues, here goes:

-- 1 -- I agree in principle, but I think Bob's suggested new text is too black/white and should be generalized.

Bob suggests:

> The case where the service provider network arranges sufficient capacity for a PW is well understood and
> will not be discussed further here. The concern is over PWs deployed independently of the service provider
> network's traffic engineering or capacity planning.

I want to include the case where capacity has been arranged, but may not be sufficient, I suggest rewriting Bob's second sentence as:

The concern is over PWs that share network capacity with elastic or congestion-responsive traffic, independent of whether that sharing is a result of the service provider network's traffic engineering and capacity planning or independent deployment of PWs by entities other than network operators.

-- 2 -- Here, I disagree.  One of the significant contributions of this draft is that TDM PWs don't cause congestion problems in practice, and one of the major reasons for that is the low latency requirements for acceptable TDM service delivery, both in ITU-T standards and in actual TDM PW deployment.  The 125us behavior of native TDM switches is relevant to the latter, and hence I prefer to include mention of it.

-- 3 -- I agree; clear captions are always a feature, not a bug ;-).

-- 4 -- I agree with changing "packet loss rate" to "packet loss probability".

-- 5 -- I firmly disagree with Bob here, although he's right that this is "techno-political" ;-).

I am concerned that S-A-F-E is likely to be a 4-letter word in wider Transport Area review, and hence, I want to use a word that does not imply anything remotely resembling an absolute guarantee that nothing can possibly ever go wrong (yes, I know Bob didn't mean to go to quite that extreme an interpretation, but S-A-F-E is liable to be read that way by those with an "axe to grind"), even though there's lots of solid operational experience that suggests all is well here.

-- 6 -- I think I'm ok with what Bob proposes to better characterize loss burstiness, but want to see specific text.

-- Circuit Breaker Mechanism --

>> [David] 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).
>>
> [Bob] I don't think we should go there. We need to keep this draft firmly as informational. If someone
> thinks a mechanism is needed because of the information in this draft, then they can write about a mechanism.

[David] I firmly disagree, but Bob and I might be talking past each other, as I do want to stay informational ;-).

This text is intended to describe an example or possibility, not to specify an implementation requirement.  The new text was intended as an OAM/OSS practice recommendation to the operator, not as a normative protocol spec.

I'm ok with inserting "example", "possibility" or something similar if that helps w/Bob's concern, but I strongly oppose doing nothing here, and note that this is also needed to respond to one of Stewart Bryant's WG LC comments.

-- PW segment size --

>> [David] 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).
>>
> [Bob] There is no need to recommend any remedial action, when we have just shown there is not a problem.

[David] Not exactly - Figure 1 shows that there is a potential concern at a combination of the high end of the range of TDM PW latencies (4ms), and higher packet loss ratios.

> Further, the "marginal problem" only applies when the TCP traffic uses packets smaller than 128B, which we only used
> as a hypothetical worst-case for the analysis. But in practice this doesn't happen with long-running TCP flows -
> they use packets that are as large as possible (irrespective of what the PW uses). So there really is /no/ problem to remedy.
Ok, Bob can relax - his transport credentials are intact, as this is an entry point to the bit-rate-congestible vs. packet-rate-congestible resource rathole that I want to ignore :-).

I believe that larger TDM PW segment sizes are a good thing for both this operating envelope boundary concern as well as per-packet processing overheads in TDM PW functionality, modulo other considerations, e.g., jitter buffers, and so I prefer to keep this addition.

Thanks,
--David

From: Bob Briscoe [mailto:bob.briscoe@bt.com]
Sent: Thursday, August 14, 2014 9:03 AM
To: Yaakov Stein
Cc: Andrew G. Malis; BOCCI Matthew; Black, David
Subject: RE: [PWE3] WGLC comments on: draft-ietf-pwe3-congcons-02.txt

Yaakov,

I have just re-read it thoroughly. I have noticed about two dozen editorial nits where correcting them would not change the intended sense (altho sometimes the sense needs to change to say what we intended!). Examples:
- Unexpanded abbreviations (David's suggestion would help, but there are more)
- Missing words, tautologies, random punctuation problems etc
- Uses of the wrong word, even tho we know what you mean
- The caveat about dynamics vs steady state needs to shift down a para, so that it follows into the para that says what to do about dynamics.

Should I take the token, and edit the XML directly, then you can see a diff to check if you want to accept my suggestions?

Below are six thoughts that go slightly beyond 'editorial'. 1-4 could be considered 'editorial'. But 5&6 are the more significant "techno-political" points.

1. The phrase "mechanisms for provisioning PWs in service provider networks" is too opaque (the PWE audience might understand this scoping sentence, but a L4 reader won't understand what we're excluding here, which will make them suspicious).
CURRENT:
   Mechanisms for provisioning PWs
   in service provider networks are well understood and will not be
   discussed further here.
SUGGESTED:
   The case where the service provider network arranges sufficient capacity for a PW is well understood and will not be discussed further here. The concern is over PWs deployed independently of the service provider network's traffic engineering or capacity planning.

2. The justification for using OWD of a few milliseconds misses the point.
"  The one-way delay
   of a native TDM service consists of the physical time-of-flight plus
   125 microseconds for each TDM switch traversed; and is thus very
   small as compared to typical PSN network-crossing latencies.
"
The 125us per switch is irrelevant. The point that needs making is that PWs are generally deployed with a short physical time of flight.

3. Related point: the captions on the graphs do not clearly indicate that they are OWD, not RTT. This could be clarified in the text, or on the graphs.

4. Change packet loss rate (and PLR) to packet loss probability throughout, including on the graph axes. PLR is an ambiguous term, even though it is widely used in the industry. Packet loss rate could be measured in packet per second, whereas packet loss probability is unambiguously dimensionless. Indeed, in the appendices, packet loss rates with respect to time are calculated.

5. Rather than David's "reasonable" I suggest we use the phrase "unambiguously safe" not just "safe" for the headings of Figs 5-8 and in the text, as below. Otherwise, we are implying that it is unsafe outside the region.

CURRENT:
   One may view this condition as defining an operating envelope for a
   TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow
   causes no more congestion than that TCP flow would.  Under this
   condition it is safe to place the TDM PW along with congestion-
   responsive traffic such as TCP, without causing additional
   congestion.  on the other hand, were the TDM PW to consume
   significantly more bandwidth a TCP flow, it could contribute
   disproportionately to congestion, and its mixture with congestion-
   responsive traffic might be inappropriate.
SUGGESTED:
   One may view this condition as defining an unambiguously safe operating envelope for a
   TDM PW, as a TDM PW that occupies no more bandwidth than a TCP flow
   causes no more congestion than that TCP flow would.  This does not draw us into a debate over whether TCP-friendliness is a valid constraint; it simply says that there can be no question that a PW is safe if it does no more harm than a single TCP flow. Under this
   condition it is unambiguously safe to place the TDM PW along with congestion-
   responsive traffic such as TCP.  On the other hand, were the TDM PW to consume
   significantly more bandwidth a TCP flow, it could contribute
   disproportionately to congestion, and its mixture with congestion-
   responsive traffic might start to cause concern.

6. The analysis in Appendices A & B needs to mention that loss bursts arise primarily from tail drop buffers, and the introduction of active queue management (AQM) makes losses more independent of each other (less bursty). (I have references showing evidence of this.) In the comparisons with TCP, we have assumed independent losses anyway, because they are the worst case (and fortunately they are easier to analyse). On a similar point, in appendix B, where we say "(bursty packet loss was also simulated but is not reported here)", we ought to give a reason otherwise readers will be suspicious. A good reason would be that uniformly random is the worst case.

I've also responded to a couple of David's suggestions inline (I agree with the others)...


At 17:44 13/08/2014, Yaakov Stein wrote:
Bob told me on Friday of the IETF that he was going to look over the final version and comment.

Bob - ping ?

Y(J)S

From: Andrew G. Malis [ mailto:agmalis@gmail.com]
Sent: 13 August, 2014 17:02
To: Yaakov Stein
Cc: Bob Briscoe; rbriscoe@jungle.bt.co.uk<mailto:rbriscoe@jungle.bt.co.uk>; BOCCI Matthew; Black, David
Subject: Re: [PWE3] WGLC comments on: draft-ietf-pwe3-congcons-02.txt

Yaakov,

I still haven't heard from Bob, but you should incorporate David's updates into a new revision, and I'll use that version for my final Shepherd's review.

Thanks,
Andy

On Mon, Aug 11, 2014 at 11:16 AM, Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:
Actually, I'm going to end the LC as soon as I hear back from Bob on the IPR call. I sent him a reminder earlier this morning.

Cheers,
Andy

On Sun, Aug 10, 2014 at 9:53 AM, Andrew G. Malis <agmalis@gmail.com<mailto:agmalis@gmail.com>> wrote:
David,

That's perfect, thanks! I'm going to end the LC tomorrow.

Cheers,
Andy

On Sat, Aug 9, 2014 at 10:32 PM, Black, David <david.black@emc.com<mailto:david.black@emc.com>> wrote:
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).

I don't think we should go there. We need to keep this draft firmly as informational. If someone thinks a mechanism is needed because of the information in this draft, then they can write about a mechanism.


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).

There is no need to recommend any remedial action, when we have just shown there is not a problem.

Further, the "marginal problem" only applies when the TCP traffic uses packets smaller than 128B, which we only used as a hypothetical worst-case for the analysis. But in practice this doesn't happen with long-running TCP flows - they use packets that are as large as possible (irrespective of what the PW uses). So there really is /no/ problem to remedy.


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).

No need to go there. See my suggestions earlier.


> 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

I wanted to suggest this myself, but it is hard to depict fuzzy boundaries. If you can do this, pls do.

Given the PW operating regions are bounded by v low loss probability, the x axis in Figs 7&8 ought to be scaled much smaller as well.

Related point: the y axis in Fig 1 ought to max at 10, not 50.

Regards



Bob

>
> 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<mailto: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<mailto:pwe3@ietf.org>
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3




________________________________________________________________
Bob Briscoe,                                                  BT
_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3

________________________________________________________________
Bob Briscoe,                                                  BT