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

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

Ugh, the spelling checker "helped" - "consequent on the quality" :-(.

Instead of this proposed new text from my original message:

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

This would be better (also reformatted as a list for clarity):

   For TDM pseudowires, such a circuit breaker can be realized via:

      1)  network operator monitoring of drop rates and the resulting
            quality of TDM service delivered; and
      2)  a network operational practice of 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 is not delivering
   acceptable TDM service (see the rest of this section, plus Appendices
   A and B).

Thanks,
--David

> -----Original Message-----
> From: pwe3 [mailto:[e-mail]] On Behalf Of Black, David
> Sent: Saturday, August 09, 2014 10:32 PM
> To: Yaakov Stein; [e-mail]
> Subject: Re: [PWE3] WGLC comments on: draft-ietf-pwe3-congcons-02.txt
> 
> 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:[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
> > >
> > >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3