Subject: Re: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt

From: <[email-masked]>
Date: Fri, 1 Mar 2013 12:42:03 +0000

Thanks Rüdiger for your feedback.

A few additional points below based on your answer.
The other points are clear for me now.

[RG] ITU class critcal (network management) is mentioned in the DiffServ-Intercon introduction:... An example for an internal PHB may be CS6...
I'm happy to expand on that, given there's support.

[SJ] I am not sure that such class would necessarily be open to interconnection. My main suggestion was not necessarily to add this class, but rather to understand why the two documents (ITU Y.1566 and this draft) were slightly different. Now it is clear, you clarified that the purpose is to have everything aligned.

[RG] Good point, I may be unclear here. I'd expect the classes to be supported. Class
definitions should stay qualitative. Class properties should be standardised. The PHBs
should be maintained in the sense that if received with different codepoints at
interconnection, they should leave with different codepoints on interconnection. So
treating different PHBs of one class only as one class is allright.
The minimum expectation then is support of a class a specified, if the Intercon class
and codepoint scheme is used. I don't think there should be an obligation to support
all four classes that's a SHOULD at best. I guess the draft needs to say that.

[SJ] I agree that class definition must remain qualitative. However, it is not fully clear to me what you mean when you say that "the class properties should be standardized". Personally, as I mentioned, I believe that it will be extremely difficult (not to say impossible) to agree on a common behavior, since various network operators have in general different configurations/policies. SLA expectations should not be part of this document IMHO, since it is a topic to be discussed between operators, on a case by case basis and depending on the context. Could you clarify your view on this point? For instance, do you expect that if an operator implements one of the class defined, then this operator must implement exactly the PHB mentioned in the draft in all the network nodes? Is there freedom left to the operator? Is there any plan to include aspects related to SLA in this draft?

Thanks.

BR,

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 28 février 2013 16:47
À : JOBERT Sebastien OLNC/OLN
Cc : [email-masked]
Objet : RE: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt

Hello Sebastien,

thanks for your comments. Your statements and my replies are marked as follows below:

[SJ] Sebastien Jobert
[RG] Rüdiger Geib

Regards,

Rüdiger

----------

     [SJ] Page 6, you mention 4 classes (Class Priority, Bulk inelastic, Assured, Default)
     with a reference to Y.1566. However, in Y.1566, the 4 classes corresponding to
     "Ordinary Packet Service QoS Classes" are not the same (e.g. Critical / network management
     class is missing in your IETF draft), and it seems that you actually mixed classes
     mentioned as "auxiliary Packet Service QoS Classes" in Y.1566 (e.g. Bulk inelastic
     belongs to this second set in Y.1566). Is there a reason for this? Should the two
     documents be aligned?

[RG] DiffServ-Intercon and Y.1566 should be aligned (and I'd add GSMA IR.34 and MEF 23.1).
ITU reached agreement on those classes all carriers support ("ordinary") and some which
see some support ("auxiliary"). ITU worked with full consensus here, not with rough
consensus. That's why I included class Bulk Inealstic in the IETF work more prominently
(but look for section 6 of Y.1566, it is proposed there too). ITU class critcal (network management)
is mentioned in the DiffServ-Intercon introduction:...An example for an internal PHB may be CS6...
I'm happy to expand on that, given there's support.

     [SJ] Page 7, you say that: "At interconnection points, the following PHBs should be
     accepted between interconnected parties:" Does it imply that it is expected that all
     the operators implement exactly these PHBs in their network in each node? It seems
     quite difficult for me to mandate that all the networks behave the same way, since
     various network operators have in general different configurations/policies. I thought
     that the original proposal was simply to define a set of codepoints for interconnection
     points, but leave the actual network behavior as operator-specific (which is quite
     reasonable). Did I misunderstand something?

[RG] Good point, I may be unclear here. I'd expect the classes to be supported. Class
definitions should stay qualitative. Class properties should be standardised. The PHBs
should be maintained in the sense that if received with different codepoints at
interconnection, they should leave with different codepoints on interconnection. So
treating different PHBs of one class only as one class is allright.
The minimum expectation then is support of a class a specified, if the Intercon class
and codepoint scheme is used. I don't think there should be an obligation to support
all four classes that's a SHOULD at best. I guess the draft needs to say that.

     [SJ] You mention the term "conditioning" at several places in your draft; could
     you define precisely what is meant by this? For instance, is it referring to
     the properties of one particular class of service? Else?

[RG] Good point and I obviously need to expand terminology. By conditioning I meant
scheduling & Active Queue Management (if any). And here "conditioning" doesn't apply
 - that has been a late change and an ill formulated one. Sorry for causing
confusion.
In fact, what's needed is something "QoS forwarding". I'm open for better suggestions.

     [SJ] About MPLS TC or Ethernet P-Bits and IP precedence, I'll tend to think that
     referencing the old IP precedence mechanism may not be the most effective way to
     explain what is suggested (and done in practice) - you might perhaps simply
     mention that the first 3 bits of the DSCP are used, it might be clearer. I
     would personally suggest not talking about IP precedence at all.

[RG] Good idea. If the WG reaches conensus that the first 3 bits of the DSCPs are used
to the purpose I specify (and in fact: specification follows implementation here)
I'm happy to rewrite the draft without refering to IP-precedence. I'll add that to the
presentation.

     [SJ] Finally, I wonder if a possible revision of RFC5127 might include most of
     the aspects discussed in this draft. Indeed, the classes (treatment aggregates)
     described in RFC5127 should ideally be aligned with this draft. Also, current
     RFC5127 contains a section 5 called "Treatment Aggregates and Inter-Provider
     Relationships". This could potentially be a place where to put some of the
     considerations on interconnection points.

[RG] Basically you are right. But to me RFC5127 requires a rewrite also without the
contents of DiffServ-Intercon. I'd be very unhappy if consensus was reached on
DiffServ-Intercon but the all is delayed because there's no consensus
on a RFC5127 rewrite. I'm open for a discussion however.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Wed, 6 Mar 2013 14:19:12 +0100

Hello Sebastien,

<snip>

  [SJ] I agree that class definition must remain qualitative. However, it is not fully
  clear to me what you mean when you say that "the class properties should be standardized".
  Personally, as I mentioned, I believe that it will be extremely difficult (not to say
  impossible) to agree on a common behavior, since various network operators have in general
  different configurations/policies. SLA expectations should not be part of this document
  IMHO, since it is a topic to be discussed between operators, on a case by case basis and
  depending on the context. Could you clarify your view on this point? For instance, do
  you expect that if an operator implements one of the class defined, then this operator
  must implement exactly the PHB mentioned in the draft in all the network nodes? Is there
  freedom left to the operator? Is there any plan to include aspects related to SLA in
  this draft?

[RG2] SLAs perfromance specifications will stay bilateral. I personally refuse to work on
performance-budget-sharing approaches in whatever standards body before operational practice
has paved a reasonable road to standardisation. It's to early for something like that today.
And IETF doesn't do that anyway, and I respect that.

[RG2] It is important to be aware that a class may be designed for traffic with specific
properties at Interconnection points, if two interconnecting parties work by per
class engineering.
What I'd like to avoid is someone looking at traffic requirements like "very low loss"
for IPTV traffic and then pick a peer network class at interconnection offering very low
loss based on the assumption of a moderate percentage of random RED drops resulting in
fast load reduction. I avoided to write "mainly UDP traffic in a class optimised for
TCP transport" here - using UDP/TCP to describe classes could be misleading.
There's a SLA however in place between interconnecting parties, which will fix service
performance. Text may be added to state, that it is the matter of a network
provider how to produce a class which has been agreed at an interconnection point.
Network internal Best Effort transport and overprovisioning is an example of a
valid option.

Regards,

Rüdiger

---

From: <[email-masked]>
Date: Thu, 7 Mar 2013 09:16:36 +0000

Thanks Rüdiger for the clarifications. I think we are in line.
SLA are to be discussed on a case-by-case basis, and we are looking here at a generic description of the interconnection classes which do not force implementations in the networks. As you mentioned, there are indeed several ways to ensure that one particular class meets certain traffic requirements (overprovisioning been one example).

Thanks.

BR,

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 6 mars 2013 14:19
À : JOBERT Sebastien OLNC/OLN
Cc : [email-masked]
Objet : RE: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt

Hello Sebastien,

<snip>

Regards,

Rüdiger