Subject: [tsvwg] review of draft-ietf-tsvwg-diffserv-intercon-00

From: <[email-masked]>
Date: Tue, 10 Mar 2015 11:26:54 +0100

Hi Bob,

thanks for your review. You have suggested to continue discussion on the list. My response [RG] in line.

We may split the discussion into more individual threads. If there's consent, I'm happy to post them again individually.

Regards, Ruediger

Sent: Bob Briscoe [mailto:[email-masked]]
Date: Monday, 9. March 2015 15:11
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]; MORTON, ALFRED C (AL); Rob SHAKIR; Achilles Petras
Subject: RE: IETF TSVWG - Could you help me by reviewing draft-ietf-tsvwg-diffserv-intercon-00

   Ruediger, David,

   I (finally) read it through last night (except the appendix). Sorry that
   this leaves you no time to do anything about it before the deadline.

   I've cc'd Rob Shakir, who is better placed to speak for BT as a whole,
   and Achilles Petras because we are working on QoS in BT with Rob.

   1) The draft glosses over its main point

   The draft focuses on the question of how to operate an internetwork using
   the idea of a set of 4 intercon classes (e.g. which 4 classes to support,
   local extensions, etc). This is fine and right, but it spends too little
   time on first exploring the pros and cons of the basic idea of having a
   set of intercon classes in the first place.

   For instance, the Intro starts
   "This draft proposes a set of standard QoS classes ... at intercon ..."

   Actually, it proposes two main things:
   a) it will be useful to have a set standard QoS classes at intercon
   b) the actual set of standard QoS classes at intercon

   This is not just a picky point. Let me explain...

   What problem is being addressed? A total of 5 words cover this (the ones
   after the comma below).
   "  Otherwise, the PHBs and
      DSCPs have to be negotiated and configured independently for each
      network interconnection, which has poor scaling properties.
   "
   I think scaling is meant to mean scaling of:
   * the negotiation efforts of the net admins,
   * the complexity of the set of remarking rules of each network,
   * the likelihood of bugs or mistakes due to this complexity
   IOW, human-related scaling problems, not a system scaling problem.

   What are the downsides of the proposed solution?
   * Interfaces will have to mark-on to a link during egress and and mark-off
   the link during ingress. That's not just a question of extra processing
   load. There's Al's question of whether all link interfaces can do that.
   If some can't, they will have to fall-back to a local agreement to do
   single remarking. Fine - still overall complexity has been reduced, but
   with some exceptions.

   * Transition from existing arrangements.
   Ultimately, not a problem, because it can be done incrementally, one
   intercon point at a time. Except someone in each network has to spend
   time doing this, and each change has to be coordinated pairwise so both
   sides do it simultaneously. Not infeasible, but that implies that /all/
   operators need to set aside time over the /same/ period of a year to
   make the transitions. So, a section on transition is needed.

   * It's nice that space is proposed for private bilateral agreements,
   and future standards. Wherever such a bilateral extensions are needed,
   human complexity scaling will remain a problem. Yes, overall, complexity
   will be confined to exceptions, not the common denominator. But the new
   schemes will constrain the exceptions into the remaining 4 codepoints.
   So the transition will reopen a need for bilateral negotiations of the
   exceptions, when the purpose of the idea was to reduce the need for
   bilateral negotiations.

   IOW, is the proposal "rearranging the deck chairs on the Titanic" after
   most of the negotiations it is trying to avoid have already concluded,
   so it will just reopen more negotiations in order to remove the need
   for future negotiations?

   I guess the idea is that there are many intercons where DS is not
   propagated at all, and you're trying to make it easier, so DS intercon
   is wider. If so, you need to say this, with evidence.

[RG] We added an applicability statement in -01 and can try to improve it.
I just note that we have to focus discussion on two issues, one of which
are the classes (PHBs) and the other are the DSCPs identifying them. You
start your comment by classes and you continue by codepoints.

[RG] Scaling also refers to automation of production. The lower the number
of variables in my configuration, the easier is automated processing.
Your list of human factors is complete.

[RG] I think, the draft already mentions the downside of one additional policy
which is required at an interconnection interface (it is one only, as either
outgoing or incoming traffic is remarked anyway when interconnecting). But we
can try to clarify pros and cons.

[RG] This draft builds around vendor limitations.
All of us will have to continue to talk to vendors. This draft doesn't try to
respect all current and upcoming vendor limitations. It tries to define
a pragmatic aim.

[RG] We should also emphasise the Informational draft character. I don't expect or
recommend any carrier to re-arrange existing interconnection arrangements.
And this work is indeed triggered by a trend to have more diffserv
aware interconnections (the Titanic is still waiting for passengers to board).

   2) A Telephony Service Treatment Aggregate?

   [RG censored a private remark here]

   The draft should say whether the concern here is queuing delay
   ('urgency') or priority during anomalies ('importance')?

   Queues in core networks drain so fast and they're so highly
   aggregated, that Diffserv will have a hard time making an
   appreciable difference to queuing delay. In core networks, DS
   is primarily used to distinguish importance (during anomalies),
   not urgency.

   If importance were the only concern, we would only need two
   classes. However, I'm OK with dividing 'important' into 'urgent'
   and 'non-urgent', which makes sense in some cases where it will
   make a smidgen of difference to jitter. So, by my arguments so far,
   these three classes make sense:
   Real-time > Assured Elastic > Elastic

   Now, is the motivation of those who want a voice class urgency
   or importance?

   * If urgency:
   I think the proponents have to prove that, assuming proper capacity
   planning, anyone would be able to tell whether the jitter of voice
   is better with a separate class than without.
   If there's a chance that mixing bulk real-time with voice will (even
   temporarily) fill the core link capacity set aside for them both,
   then that's an issue of importance, not urgency (see next).

   * If importance:
   Is this because some operators have historic regulatory obligations
   around voice? Otherwise, it's hard for any operator to judge whether,
   during an anomaly, it is more important to preserve someone's voice
   call than their conversational video call. Isn't this a subjective
   and/or commercial question that is hard to pre-judge in any standards
   body. I guess one could argue that voice is smaller than video, and
   therefore /easier/ to preserve, which makes it worth segregating.

   The answer to these questions should determine whether a Telephony
   Treatment Aggregate is an industry-wide need (and therefore worth
   one intercon DSCP) or just the irrational desire of some operators
   who get a warm feeling from having a voice class (and therefore, it
   should be added by bilateral agreement only).

[RG] If I was building a greenfield diffserv aware backbone, it had
just the three classes you mention.
There's a need for one Telephony DSCP (could be part of the Real-Time
Class and DSCP set, if just three classes are interconnected). At the
access, telephony traffic still requires "urgency" (assuming that access
speeds below say 50 Mbit/s to customer remain operational for a while).
Regulated access to a network operating a telephony class usually requires
not to discriminate at wholesale interfaces.
Accounting for billing may be an issue, if done at the interconnection
for a telephony class (even if transport in the backbone is in a real
time class).
So I'd like to retain a telephony class as an option at least.

   3) PHP

   I think I'm correct in saying that the problems with PHP and the
   Short Pipe Model exist irrespective of this new proposal for a set
   of intercon classes. Nonetheless, the PHP problem /is/ intertwined with
   the question of whether to remark unrecognised traffic to bridge that
   'gap' across the penultimate hop (see next point).

   So I would advise that these two issues (PHP and 'bleach unrecognised')
   are dealt with together, but separated out into a different draft.

   [RG removed a possibly private remark, saying Bob here is the devils
   advocate], I have to say this: PHP only exists to minimise decap processing
   at the egress. So it would be so ironic, and prove just how incapable we
   all are of controlling what our vendors sell us, if we end up adding an
   extra layer of tunnelling just to work round PHP.

[RG] To me you've clarified a good point by the middle statement. David may
have pushed the draft in a direction you describe too.

   4) Bleach unrecognised?

   I don't think /this/ draft should address this issue. It's a more general
   problem that applies irrespective of whether you use standardised intercon
   classes or not. Attempting to address the two issues together could kill
   or severely delay this draft.

   However, this issue does need to be addressed, but in a separate draft,
   to come down clearly on one side or the other on whether operators should
   solely treat unrecognised DSCPs as CS0, or remark to CS0 as well. However,
   I've started another thread about that, whether or not you agree it should
   be separate, we can talk about it separately.

[RG] I will forward and respond to your separate mail.

   5) Document Comprehensibility

   # It would be useful if the draft contained a more fine-grained diagram
   that shows the queue where a PHB is applied and the point at which
   remarking is applied, on egress and on ingress. Then another diagram
   showing how this is meant to work with PHP. These two points are the
   essence of the proposal, but they are explained a number of times
   unclearly rather than once clearly.

   # I suggest the Intro is discarded and a fresh Intro is written.
   There are some very good parts, but it jumps all over the place, and
   it's a bit too long/detailed for an intro.

   # Personally, I would prefer more sub-headings in an RFC, so it is
   easier to refer to the individual subject areas. The sections are
   long (e.g. S.3. is over 5 pages before you get to 3.1). And each
   section covers numerous smaller subjects (e.g. in S.3 there could
   be sub-headings for "Example Scenario", "Extension to support
   bilateral SLAs", etc.).

   # "End-to-end" is understood differently by different communities.
   I suggest you clarify.
   a) Some people say e2e when they mean at every hop.
   b) Other people say e2e when they mean the same at the two ends
   (ie. encapsulated across the middle)
   The fact that you say "This [e2e QoS] will initially be possible
   for PHBs and DSCPs corresponding to at most 3 or 4 Treatment
   Aggregates..." implies you are thinking of meaning (a).

   But actually, this new intercon model can support 2^6 classes e2e,
   if e2e has meaning (b). Because, as your draft points out, the
   intercon model could sit underneath the RFC2983 pipe model, by
   using tunnelling.

   # The scoping statement about the applicability also covering
   802.1p at the end of S.3 (just before 3.1) seems to be in the
   wrong place.

[RG] What's meant by end-to-end should be clarified. Treatment
aggregates are limited to backbones. Provider and
Customer Edge nodes may e.g. apply MF classification and operate a
different set of PHBs.
The scoping statement related to 802.1p and others - I'll consult
David where to best move it.

[RG] Appendix/Annex B offers some PHP related figures. If they cover
some aspects you mention, feedback on the missing ones would be great.

[RG] David is trying hard to make the document better readable (-01
Intro is improved against -00). Thanks for your help and sorry for
my badly structured argumentation.

   6) Nits

[RG-final] David found and removed some and I picked up most of the remaining Nits below. The one about traffic engineering - my statement doesn't refer to MPLS RSVP TE. I assume all carriers to operate engineered backbones (whether they are MPLS based or not). I hope, that's reasonable.

   Globally:
   *  "...ordinary network traffic." (x3)
     Please define, and please use a more accurately descriptive term. I
     think you mean non-tunnelled traffic.
   *  s/pen ultimate/penultimate/
      s/pen-ultimate/penultimate/

   1. Intro
   *  "foundation, foundation,"
   *  "assumes robust provider backbone traffic engineering"
      (doc applies to any MPLS operator, whether using TE or not)
   *  "RFC5127 recommends transmission of DSCPs as they are received.  This
      is not possible, ..."
      I suggest this para is deleted. RFC5127 was surely not talking about
      intercon when it made the recommendation - it surely wasn't attempting
      to contradict RFC2475's point that remarking is a feature.

   1.1 Related Work
   *  "basic Diffserv elements for network interconnection are used as
       described in this doc"
     I think you just mean "when the scheme in this doc is used"

   3. Intercon scheme

   *  s/This sort of of/This segregation of/
   *  "       compared to RFC 5127, the number of DSCPs has been reduced to
             one (initially) and the proposed queuing mechanism. "
      (sentence ends in mid-air)
   *  "At this state, the Bulk Real-Time Treatment Aggregate
                or the Bulk Real-Time Treatment Aggregate may be a reasonable match."
      (You clearly meant something else here.
       And s/At this state/Currently/)
   *  s/Assume all providers to run/
       /Assume all providers run/
   *  s/PHB groupwith properties/
       /PHB group with properties/
   *  Fig 1: I guess "DSCP rew." means "DSCP rewrite". Not obvious.
   *  "At the outgoing peering interface connecting provider W with provider
      T remarks CS3 traffic ..."
      (subject of sentence missing)
   *  s/CS3 traffic to AF31 and CS 2 traffic to CS32/
       /CS3 traffic to AF31 and CS2 traffic to AF32/
   *  s/ist/is/ (already pointed out)
   *  s/router od domain T/
      /router of domain T/

   3.1 E2E QoS & Transparency
   *  s/why PHB and g DSCP/
       /why PHB and DSCP/
   *  s/it is certainly no Network Control traffic/
       /it is certainly not Network Control traffic/

   Bob

At 19:03 13/01/2015, MORTON, ALFRED C (AL) wrote:

Hi Rudi,
you asked:
        RG>> The draft covers mainly public IP interconnections and may be used for
        similar types of IP interconnections. Not sure about *all* - what do you have
        in mind?

The different PHY and Link layer interfaces on routers, or different interface engines,
or flavors of composite/LAG interfaces, may *not* all have the ability to
"mark-on" to the link and also "mark-off" the same link.  Need both.

Al

> -----Original Message-----
> From: [email-masked] [ mailto:[email-masked]]
> Sent: Tuesday, January 13, 2015 3:31 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: IETF TSVWG - Could you help me by reviewing draft-ietf-tsvwg-
> diffserv-intercon-00
>
> Hi Al,
>
> thanks, some RG>> marked replies in line.
>
> Regards, Ruediger
>
> End of Section 2:
>
>    If transport of a large number (much greater than 4) DSCPs is
>    required across a network that supports this DiffServ interconnection
>    scheme, a tunnel or VPN can be provisioned for this purpose, so that
>    the inner IP header carries the DSCP that is to be preserved not to
>    be changed.  From a network operations perspective, the customer
>    equipment (CE) is the preferred location for tunnel termination,
>    although a receiving domains Provider Edge router is another viable
>    option.
>
> It strikes that the interconnecting operators need to:
> - further agree on the tunneling technology + interconnecting PHB(s)
> - appreciate the impact of tunneling on reliability and MTU and it
>   would be good to add those points.
>
> RG>> Yes, text may be added (in an annex?). My view:
>      - The tunneling method is what RFC5127 and RFC3270 expect. The easy
>        way out is to point to these RFCs (??). If not, let's add
>      - The diffserv-intercon PHBs may be used for transport within the
>        provider domain.
>      - The sending domain maps the inner tunnel PHBs to the DiffServ
>        intercon PHBs.
>      - Tunneling needs to be discussed between interconnection partners,
>        if equipment of both parties is involved (true for MPLS VPNs or
>        L2TP). Or if changing outer tunnel DSCPs has an impact (generally
>        applying DiffServ Intercon DSCPs when sending/receiving traffic
>        may help here).
>      - Reliability - do you means issues like protecting tunneling
>        signaling - mentioning that yes, but details should be added in
>        a draft handling tunneled DiffServ. That's not in scope of
>        this draft.
>      - MTU is an issue, I agree. I can't tell how to provide a 1500 Byte
>        "inner" IP MTU however if I'd like to set up a tunnel on an access
>        offering an "outer" IP MTU of 1500 Byte (or less). Of course, no
>        one has ever had customers asking for that...
>
> Some unstated requirements of Section 3:
> Peering routers need to have re-marking capability for *all* interface
> types
>
> RG>> The draft covers mainly public IP interconnections and may be used
> for
> similar types of IP interconnections. Not sure about *all* - what do you
> have
> in mind?
>
> [CS 6 - David replied]
>
> The end of section 3.2 has a case where you need a special SLA for CS6:
>
>    o  classification of traffic which is network control traffic for the
>       sending domain only.  This traffic should be classified for a PHB
>       offering similar properties as the NC class (e.g.  AF31 as
>       specified by this document).  As an example GSMA IR.34 proposes an
>       Interactive class / AF31 to carry SIP and DIAMETER traffic.  While
>       this is service control traffic of high importance to the
>       interconnected Mobile Network Operators, it is certainly no
>       Network Control traffic for a fixed network providing transit.
>       The example may not be perfect.  It was picked nevertheless
>       because it refers to an existing standard.
>
> Are you mostly pointing out that IR.34 doesn't address NC/BGP traffic, so
> it's not really adequate as a candidate spec for general interconnect
> attempting to support more than default behavior?  I think you might be...
>
> ;-)
>
> RG>> I personally don't favour IR.34 as a general interconnection
> standard. Their definition of the "Interactive" class makes them a tunnel
> solution candidate.
>
> I noticed a bunch of typos in Sec 3, under Figure 1, such as:
> the MPLS TC ist set to 2.
> s/ist/is/
>
> RG>> That one may be caused by autocorrection ("ist" is German for "is").
> Intelligent software often is a good thing. But a detailed review is
> definitely missing.
>
>
> I didn't have time for the Annexes.
>
> hope this helps, sorry for the delay,
> Al
>
>
>
> > -----Original Message-----
> > From: [email-masked] [ mailto:[email-masked]]
> > Sent: Monday, January 12, 2015 3:06 AM
> > To: MORTON, ALFRED C (AL); [email-masked];
> > [email-masked]; [email-masked]
> > Subject: IETF TSVWG - Could you help me by reviewing draft-ietf-tsvwg-
> > diffserv-intercon-00
> >
> > Dear Colleagues,
> >
> > I hope you had a good start into 2015.
> >
> > I've asked you for a review of (now named) draft-ietf-tsvwg-diffserv-
> > intercon-00 in November 2014. My co-author (D. Black, TSVWG co-chair)
> > reminded me of the missing reviews by other provider representatives,
> > which are required.
> >
> > If you or the provider you work for will not be able to review the
> > document, please drop a note. I'll stop bothering you then. I know
> > MPLS experts of BT and Orange, but they usually point out that they
> > aren't QoS experts - that's why I contact you.
> >
> > I'm aware of shortcomings of todays DiffServ implementations. The
> > draft proposes a (simple, hopefully) aim, how DiffServ Interconnection
> > could result in end to end PHBs without having to adapt provider
> > internal QoS production. I think, unless we reach specified IETF
> > solutions meeting provider requirements, partially IETF compliant
> > vendor QoS implementations may last for while.
> >
> > We plan a major review before the next IETF (draft cut-off is 9. March).
> > Your responses would be appreciated prior to that date.
> >
> > Regards,
> >
> > Ruediger
> >
> > --------------------------------------------------
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >  This draft is a work item of the Transport Area Working Group Working
> > Group of the IETF.
> >
> >         Title           : DiffServ interconnection classes and practice
> >         Authors         : Ruediger Geib
> >                           David L. Black
> >      Filename        : draft-ietf-tsvwg-diffserv-intercon-00.txt
> >      Date            : 2014-12-04
> >
> > Abstract:
> >    This document proposes a limited and well defined set of DiffServ
> >    PHBs and codepoints to be applied at (inter)connections of two
> >    separately administered and operated networks.  Many network
> >    providers operate MPLS using Treatment Aggregates for traffic marked
> >    with different DiffServ PHBs, and use MPLS for interconnection with
> >    other networks.  This document offers a simple interconnection
> >    approach that may simplify operation of DiffServ for network
> >    interconnection among providers.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-tsvwg-diffserv-intercon-00
> >
> >
________________________________________________________________
Bob Briscoe,                                                  BT