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

[Bob Briscoe <[e-mail]>]

David,

Sry for delay. inline...

(Despite end of WGLC, we can still continue our 
public intra-author ping-pong :)

At 13:44 18/08/2014, Black, David wrote:
>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.

I wanted a different word from 'acceptable' for 
the adjective in the captions above the Figures 
describing the regions, because there's no 
opportunity for more text there to explain that 
we do not mean that outside the region is 
unacceptable. I thought about various qualifiers 
with acceptable (like clearly, unarguably, etc), 
but I don't think these are right either.

I figured that the curves that delineate the 
region are defined by the TCP-friendly equation, 
so 'friendly region' says on the tin what it does 
(and it is OK to imply that outside the region is 
unfriendly, because unfriendly doesn't imply 
"Don't go there" like 'unacceptable' would).

Let's stop batting back & forth until we see what Yaakov (or others) think.


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

If we're going to say a bit about how to realize 
a circuit-breaker, I'd be happier with the word 
persistently than without. I'd still rather we 
didn't allow this draft to mission creep into mechanism mode.

In fact, on reflection, whatever we say about 
circuit-breakers, I'd prefer not to mention 
circuit-breakers in the abstract, which implies 
this draft says stuff about mechanism, which was never the intent.

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

Not so - that's the problem. On these graphs, the 
op behaviour plots won't move at all if the PW 
uses larger packets. These are bit-rate plots, so 
the only way to move anything is to change the 
TCP segment size (which moves the TCP plots). To 
justify what you want to say, either:
a) these would have to be packet-rate plots, or
b) we would have to turn the assumption we've 
made about equal packet sizes into an operational 
requirement, not just an analytical assumption.

To go in either of these directions would require a spade and vermin.


Bob

PS. GOing offline until next Tue. Might check email, but no guarantee.

>
>Thanks,
>--David
>
>From: Bob Briscoe [mailto:[e-mail]]
>Sent: Friday, August 15, 2014 6:03 AM
>To: Black, David
>Cc: [e-mail]
>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:[e-mail]>mailto:[e-mail]]
>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:[e-mail]>mailto:[e-mail]]
>Sent: 13 August, 2014 17:02
>To: Yaakov Stein
>Cc: Bob Briscoe; 
><mailto:[e-mail]>[e-mail]; 
>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 <<mailto:[e-mail]>[e-mail]> 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 
><<mailto:[e-mail]>[e-mail]> 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 
><<mailto:[e-mail]>[e-mail]> 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:[e-mail]>mailto:[e-mail]] 
> On Behalf Of Yaakov Stein
> > > Sent: Thursday, July 24, 2014 4:52 PM
> > > To: <mailto:[e-mail]>[e-mail]
> > > 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
> > <mailto:[e-mail]>[e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
>
>_______________________________________________
>pwe3 mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/pwe3
>
>
>
>
>________________________________________________________________
>Bob Briscoe,                                                  BT
>_______________________________________________
>pwe3 mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/pwe3
>
>________________________________________________________________
>Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT