Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

From: Stewart Bryant <[email-masked]>
Date: Tue, 01 Jul 2008 11:33:13 +0100

Maarten Vissers wrote:
>  Yaakov,
>
>   
>> In my analysis I assume that the MPLS is indeed TE, but the PWs are not. 
>> So we know that the MPLS tunnel can handle, say 1 Gbps, but we load it
>> with 20 PWs each of which peaks at 100 Mbps. What do we do now ?
>>     
>
> If each PW peaks at 100 Mbps, then each PW has an EIR of (100-CIR) Mbps.
> What is the CIR of each of those PWs? 
> Assume that the CIR for each PW is 25 Mbps, then the tunnel with CIR = 1
> Gbps will carry 20 PWs, each with 25 Mbps CIR (total thus 500 Mbps CIR). 
>
> When a PW carries temporarily a peak rate of 100 Mbps, then 25 Mbps is
> marked as non-discard eligible (Green packets) and the remaining 75 Mbps is
> marked discard eligible (Yellow packets).
It's not as easy as that. The only way you can mark a packet is to set 
the QoS bits, and
routers (LSRs) will then put them in different queues.

This has a couple of problems, first you get missordering when you 
change from
yellow back to green, and secondly you will tend to tail drop, which reduces
the throughput.

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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 02 Jul 2008 07:56:40 +0200

Stewart,

The UNI-N ports are equipped with Traffic Conditioning functions which set
the network QoS bits (i.e. classification and metering). 
A service with CIR=25M and EIR=75M supported by a PW will cause that the QoS
bits of the PW packets are set such that the CIR/EIR configuration is met.
Inside the network there is no recoloring for MS-PWs. Inside the network
yellow packets will be discarded when there is a temporarily overload of a
link.

If a service can't tolerate any discards (e.g. a TDM service) then EIR=0 and
all packets are green packets.
The network will not discard those green packets if connection admission
control and traffic engineering are deployed correctly.
If oversubscription of CIR is implemented, then green packets may also
experience discards. Such will degrade the services.
But this is a choice of the operator, which we can not and should not try to
'correct' or make 'less painful' by complicating the standards, and
consequently the equipment and netowrk operation.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: 01 July 2008 12:33
To: Maarten Vissers
Cc: 'Yaakov Stein'; 'Bruce Davie'; 'Stewart Bryant'; [email-masked]; 'Danny
McPherson'
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Maarten Vissers wrote:
>> So we know that the MPLS tunnel can handle, say 1 Gbps, but we load 
>> it with 20 PWs each of which peaks at 100 Mbps. What do we do now ?
>>     
>
> Assume that the CIR for each PW is 25 Mbps, then the tunnel with CIR = 
> 1 Gbps will carry 20 PWs, each with 25 Mbps CIR (total thus 500 Mbps CIR).
>
> marked as non-discard eligible (Green packets) and the remaining 75 
> Mbps is marked discard eligible (Yellow packets).
It's not as easy as that. The only way you can mark a packet is to set the
QoS bits, and routers (LSRs) will then put them in different queues.

This has a couple of problems, first you get missordering when you change
from yellow back to green, and secondly you will tend to tail drop, which
reduces the throughput.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 04 Jul 2008 10:55:41 +0200

Retry...

 Yaakov,

When all PWs carry temporarily their peak rate, then there is 1.5 Gbps EIR
traffic and 0.5 Gbps CIR traffic applied to the tunnel ingress; 0.5 Gbps CIR
traffic is passed over the tunnel and 33% of the EIR traffic is passed over
the tunnel (1 Gbps of EIR traffic is discarded).

This network behaviour fully complies with the SLAs of the 20 services. So
the customer is happy.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: 30 June 2008 14:33
To: [email-masked]; Bruce Davie
Cc: Stewart Bryant; [email-masked]; Danny McPherson
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Stewart,  

> To use an analogy : you could operate a stream engine without a safety
valve and indeed in the early days people did. 
> All it takes is vigilance to make sure the pressure  never goes above
limits even when  the  driver is  dealing with  other emergencies.
> So no problem safety mechanisms are not need on the railway.
> So back to our case here. We assume that the operator will set the
thresholds so that the congestion cut off never gets invoked
> - unless there is a real problem in their network, in which as the
shedding of PW load will be the least of their problems.

So, if I understand you correctly, you are saying that this draft is a
framework for a mechanism that will never really be used for a service
provider network. This was precisely my point.
 
> > So, what IS congestion control for PWs ?
> > Well, due to the unfortunate decision detailed in RFC 3468 and the 
> > interpretation that this limits PWE3 from extending its control 
> > protocol to include BW reservations, we have to accept the situation

> > that PWs are not properly BW limited.
> > So, we can't talk about a PW's committed rate (CR), and thus even if

> > we deny admission when we believe we don't have sufficient BW, we 
> > can't properly enforce CR and excess rate schedules.

> Wait a moment, there is nothing to stop you running PW over MPLS-TE,
that has the properties that you are looking for.

Sorry, that is not the same thing. In my analysis I assume that the MPLS is
indeed TE, but the PWs are not. So we know that the MPLS tunnel can handle,
say 1 Gbps, but we load it with 20 PWs each of which peaks at 100 Mbps.
What do we do now ?

Well, we could
1) have a centralized management system force each PE to police to rates
that sum to < 1 G
2) have a distributed mechanism whereby packet drop causes each PE to police
down
    to a percentage of the "expected maximum rate" (I hesitate to call this
committed).
3) use the TCP/IP mechanism whereby packet drop causes halving the rate
4) use a TCP-like or TCP-friendly mechanism which polices to a "fair BW"
(not fair degradation!)
    but does not know which internal flows it effects
5) use a TCP-friendly mechanism coupled with DPI to mimimize effect on
flows.

> The unfortunate problem is that in congestion work the unit of
currency is the "TCP flow". 
> So what unit of currency would you propose that is common to both PW
and non-PW traffic?

That unit of currency is only meaningful in the context of individual user
TCP flows.
I am claiming that it does make sense in a PW context, and treating PWs as
an equivalent number of flows is both a blunt tool, and leads to internal
TCP flows being badly treated as compared to external ones.

> For example PW over L2TP, or PW over MPLS over GRE over IP.

Yes, PW over L2TPv3 or L2TP over UDP are possible.
Are you talking about IPsec transport or tunnel mode here?
I am trying to figure out what the packet looks like.
I guess, for IPv4 tunnel mode :
   outside IP header, IPSec AH and/or ESP headers, inside IP header, L2TP
header, PW payload, ESP trailer

> > BTW, for TDM PWs packet arrival times can also be used as a very 
> > sensitive mechanism to detect imminent congestion.
> Can you propose some text?

Actually, we had a lot of text about the TDM PW case in RFCs 4553, 5086 and
5087.
I can provide some text about using the arrival times.

Y(J)S

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 04 Jul 2008 11:44:50 +0200

Stewart,

After sending my initial response, I noted that there may be a
misunderstanding concerning:
- coloring (green, yellow, or red) and
- classifying (CoS set to 7,6,5,4,3,2,1, or 0).

Coloring packets Green/Yellow has to do with setting the 'Discard Eligible'
information. 
Green: discard eligible = false
Yellow: discard eligible = true.

Classifying packets has to do with setting the Class of Service (CoS) value
to a value in the range 7 to 0.

The CoS value puts the packets into specific queues.
E.g. CoS=4 packets go via e.g. Queue C. Both CoS=4 Green and Yellow packets
will go via Queue C. 
Remarking (i.e. recoloring) those CoS=4 packets from Green to Yellow will
not change the queue.

In packet transport networks there are typical four types of traffic:
1) network control traffic
2) time-critical, guaranteed-deliviry traffic (e.g. TDM, video, voice)
3) non-time-critical, guaranteed-delivery traffic
4) non-time-critical, no-guaranteed-delivery traffic

Only non-time-critical traffic should be recolored.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maarten Vissers
Sent: 02 July 2008 07:57
To: [email-masked]
Cc: 'Danny McPherson'; 'Bruce Davie'; 'Yaakov Stein'; [email-masked];
'Stewart Bryant'
Subject: Re: [PWE3] WG LC:draft-ietf-pwe3-congestion-frmwk-01.txt

Stewart,

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: 01 July 2008 12:33
To: Maarten Vissers
Cc: 'Yaakov Stein'; 'Bruce Davie'; 'Stewart Bryant'; [email-masked]; 'Danny
McPherson'

Stewart