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

["Black, David" <[e-mail]>]

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:

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.

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.

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?

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

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.

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

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.

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.

Thanks,
--David


> -----Original Message-----
> From: pwe3 [mailto:[e-mail]] On Behalf Of Yaakov Stein
> Sent: Thursday, July 24, 2014 4:52 PM
> To: [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
> 
>