Subject: RE: [PWE3] RE: Proposed MS-PW "QoS" Requirements Clarifications

From: [email-masked]
Date: Mon, 4 Apr 2005 16:40:38 +0100

Eric,

> Richard> Dave, Regarding your suggestion to carry parameters such as the
> Richard> average rate, burst duration and peak rate, and your references to
> Richard> RFC2697/RFC2698, I assume that this is to support per MS-PW
> Richard> policing/queuing at S-PEs?  
> 
> I thought it was more to enable mapping of the PEs to appropriate  TE
> tunnels. 

How? To map MS-PWs to TE tunnels requires the traffic parameters carried in the signalling protocol to match TE tunnel properties/characteristics (e.g. an EXP value mapping to a DS-TE tunnel). Lets take burst duration for example, if a S-PE gets a MS-PW setup request with a requirement for a 2sec burst, how does this help the S-PE select an appropriate TE tunnel? Also, RFC2697/RFC2698 describe single/two rate three colour marking, what do these have to do with TE tunnel mapping? 

> Richard> One case where per MS-PW policing will be needed is at border S-PEs
> Richard> where a provider may not trust another provider to police
> Richard> individual MS-PWs correctly
> 
> I'm  not sure  I understand  why  per-PW policing  is needed  
> at the  second provider, as opposed to some sort  of aggregate policing.

Aggregate policing allows the provider to ensure that there is enough bandwidth in the network to meet the requirements of the aggregate, but does not provide fairness between MS-PWs within the aggregate. For example, you could use aggregate policing to ensure that a S-PE never accepts more than 10Mbit/s of Class 1 traffic from another provider. However, if the other provider hasn't policed the individual MS-PWs, then some of the MS-PW packets may be in-contract and some may be out-of-contract. As there is no way to distinguish between in-contract and out-of-contract packets within a class, when the amount of class 1 traffic received exceeds 10Mbit/s some in-contract packets will be dropped and some out-of-contract packets will get through. So, a customer that buys 500Kbit/s of class 1 traffic and is only transmitting 400kbit/s, may have packets dropped because another customer who has also purchased 500Kbit/s of class 1 traffic is actually sending 1Mbit/s.

Also, aggregate policing only works if there is a hard limit on traffic class bandwidth. If the QoS model supports re-use of unused bandwidth between classes, i.e. classes can burst if bandwidth is available, then this approach won't work.

> Then if the first provider is not policing properly, the enduser service  
> might not work properly, but presumably that's the fault of the first  
> provider, and it's the first provider who has direct contact with the enduser anyway.

No, in an inter-provider case where one user of the service (e.g. user A) is in one providers network (e.g. SP1) and the other user (e.g. user B) is in another providers network (e.g. SP2), then both users are likely to be affected as communication is generally two-way. Even if the communication is more one way (e.g. a UDP file transfer request) and if SP2 is not policing at the edge, then it will actually be user A in SP1s network that will be affected.

Dropping in-contract packets because the other provider is sending too many out-of-contract packets (due to not policing correctly) is a difficult subject when it comes to blame and responsibility. I don't think the response "Well SP2 is sending me more traffic than it should be for customer X and Y, so that's why I'm dropping half of your packets I'm afraid customer Z" would go down too well. The customer has a contract with the providers and doesn't care what agreements the providers have with each other.

It appears to me there are only two alternatives:

1. You use aggregate (e.g. class based) policing with hard bandwidth limits on each class at border S-PEs, and you sign an agreement with the other provider that says if the traffic it sends exceeds agreed class limits (forcing you to potentially drop in-contract traffic within a class) then they will take full responsibility and compensate the customer accordingly. 

2. You perform per MS-PW policing.

If there are other alternatives I'd be interested in hearing about them?

> If you really want per-PW policing and shaping at each S-PE, then the proper
> model may be that each segment looks like an access circuit to  the next
> segment. That might turn out to be very different than the model in which
> the S-PE points are transparent to the data plane.

I'm not sure exactly what you mean here, the S-PE points are transparent to which data plane? - The tunnel LSP, the MS-PW, or the client (e.g. AT,, Ethernet, TDM, etc.) data plane? If you are referring to the client, then this should always be transparent to S-PEs. 

> Richard> One case  where per MS-PW queues (and  associated traffic counters)
> Richard> could  be  used  is at  border  S-PEs  to  obtain per  MS-PW  usage
> Richard> information in order to support usage based inter-provider charging
> Richard> models.
> 
> Support for this charging model requires per PW usage information, but not
> per-PW queues. 

Agreed, although I didn't say anything to the contrary. I said that MS-PW queues could be used to support usage based billing, I didn't say that there weren't any other methods.

> But do you really plan to have per-pseudowire usage-based 
> inter-provider billing?

The commercial and regulatory requirements for inter-provider MPLS/PWs have not been defined yet, and therefore I would not like to speculate on what inter-provider billing requirements will be. I would say though that usage based billing as opposed to flat rate billing for packet based services appears to be gaining significant interest. For example, Korea Telecom plans to introduce usage based billing for Internet access around 2007 in order to address peer-to-peer traffic concerns and to introduce fairness, i.e. those customers that use the network the most will pay the most.
 
Regards,
Richard

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Eric Rosen <[email-masked]>
Date: Thu, 07 Apr 2005 10:44:11 -0400

> To map MS-PWs to TE tunnels requires the traffic parameters carried in the
> signalling protocol to match TE tunnel properties/characteristics (e.g. an
> EXP value mapping to a DS-TE tunnel).  

Yes, I thought that that was the requirement being posed by at least some of
the folks who want QoS signaling for PWs. 

> if a S-PE gets a MS-PW setup  request with a requirement for a 2sec burst,
> how does this help the S-PE select an appropriate TE tunnel 

If it doesn't, maybe there's no need to signal it. 

> As there is no way  to distinguish between in-contract and out-of-contract
> packets within a class 

So, the requirement you are posing here is the need for a method by which an
S-PE  can  distinguish   in-contract  from  out-of-contract  packets.   This
requirement is there to handle the following case: 

- SP  A accepts  more traffic  from  its endusers  than it  is obligated  to
  accept,

- SP A sends SP B more traffic than SP B is obligated to accept from SP A. 

One might  think that SP A  is at fault here,  but perhaps SP B  wants to do
what it  can to compensate for  SP A's shoddy practices.   However, since in
general SP B cannot  compensate for shoddy practices on the part  of SP A, I
don't understand why this particular case is worth a large investment on the
part of SP B.

In any  event, if  there is a  valid requirement to  distinguish in-contract
from out-of-contract  packets at the switching point,  having each switching
point try to perform that  classification itself is not necessarily the best
solution.

> I'm not sure  exactly what you mean here, the  S-PE points are transparent
> to which data plane? - The tunnel LSP, the MS-PW, or the client (e.g. AT,,
> Ethernet, TDM, etc.) data plane? 

I meant  to the  MPLS data plane.   I think  it should be  a goal  that data
packet  switching  at  the  S-PEs  be  done  by  "ordinary"  MPLS  switching
procedures, which  have no knowledge that  they are functioning  in an S-PE.
I'm sure this goal will need to be compromised to some degree, as it may be
necessary to process  in-band control channel info, if there  is any.  But I
think the solution becomes much more  expensive if the S-PE has to the exact
same per-PW processing that is done at the PW ingress and PW egress.