Subject: [PWE3] congestion considerations with pseudo-wires

From: Yakov Rekhter <[email-masked]>
Date: Thu, 09 Nov 2006 08:43:26 -0800

Folks,

I would like to propose the following to address the issue
of how to handle congestion with pseudo-wires.

   Congestion Considerations

   A pseudo-wire can carry a number of different protocols as
   payloads. When a pseudo-wire carries IP-based traffic, the
   aggregate traffic is assumed to be TCP friendly due to the
   congestion control mechanisms used by the payload traffic. Packet
   loss will trigger the necessary reduction in offered load, and
   no additional congestion avoidance action is necessary.

   When a pseudo-wire carries payload traffic that is not known to
   be TCP friendly and the pseudo-wire runs across an unprovisioned
   path, the application that uses the pseudo-wire MUST employ
   additional mechanisms to ensure that the offered load is reduced
   appropriately during periods of congestion. The pseudo-wire flow
   should not exceed the average bandwidth that a TCP flow across
   the same network path and experiencing the same network conditions
   would achieve, measured on a reasonable timescale.

   The comparison to TCP cannot be specified exactly but is intended
   as an "order-of-magnitude" comparison in timescale and throughput.
   The timescale on which TCP throughput is measured is the round-trip
   time of the connection. In essence, this requirement states that
   it is not acceptable to deploy an application using the encapsulation
   specified in this document on the best-effort Internet, which
   consumes bandwidth arbitrarily and does not compete fairly with
   TCP within an order of magnitude. One method of determining an
   acceptable bandwidth is described in [RFC3448]. Other methods
   exist, but are outside the scope of this document.

Yakov.

P.S. I do not claim the authorship to the above text - it was
taken, almost verbatim, from another document...

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 9 Nov 2006 09:33:17 -0800

Hi,

> of how to handle congestion with pseudo-wires.
...
> taken, almost verbatim, from another document...

that document was draft-ietf-mpls-over-l2tpv3, which is important,  
because we crafted these original considerations specifically for  
MPLS/L2TPv3 flows. They do not apply for TDM PWs and other flows that  
do not reduce offered load under packet loss.

Furthermore, note that these considerations to not specify a  
mechanism for congestion control, they merely provide some guidance  
on how such a mechanism should behave. They are in that sense similar  
to Section 6.5 of RFC3985, which also only provides guidance - and a  
requirement for - such mechanisms, without detailing a solution.

I agree that this text is a useful starting point for _one kind_ of  
PWs, but it is neither complete nor detailed enough to be a solution  
for the overall issue.

Lars

-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 09 Nov 2006 20:53:31 +0000

Yakov,

These issues are being discussed in tsv-area (or tsvwg) at the mo.

It's probably best for me not to start discussing them in PWE3 as well, as 
resolution of the current crisis in thinking could confuse people who just 
need the conclusions. But below I give a taster, and if anyone is 
interested, they should join the tsv-area discussion I guess.

At 16:43 09/11/2006, Yakov Rekhter wrote:
>    [...]
>    appropriately during periods of congestion.

Agree

>The pseudo-wire flow

Why one TCP? Why not 2? Or 5? Or 1000?

Why should a pseudo-wire containing many TCP-compatible flows be able to 
get the equivalent rate of many TCPs (all contained within the pseudo-wire) 
while as soon as it contains anything that is even slightly 
non-TCP-compatible it has to restrict itself to the equivalent rate of just 
one TCP? A Web browser gets 4. Bit Torrent gets 50.

1000 TCP flows are OK across the Internet (as long as they are not 
correlated which could cause instability), because they all back off when 
there is congestion. No-one cares how much rate they attain when there 
isn't congestion.

The point I'm making is that the rate is not the issue, it's the response 
to congestion as well, which is to do with the dynamics. And if we're 
primarily concerned about congestion collapse and stability, we're much 
more concerned about the dynamics than the first order average.

The trouble is that a pseudo-wire that is "not known to be TCP friendly" is 
a meaningless phrase, because "TCP friendly" is a meaningless phrase (it is 
defined, but meaninglessly defined).

I explain the broken logic of TCP-friendliness in the I-D I posted a few 
weeks ago and just presented at TSV-AREA:

Flow Rate Fairness: Dismantling a Religion
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>

Abstract: We were moved to write this memo because the applied research and 
standards communities in networking are using completely unrealistic and 
impractical fairness criteria. The issue is not whether they should use 
this or that allocation scheme; they don't even allocate the right thing 
and they don't allocate it between the right entities. We explain as 
bluntly as we can that sharing out flow rates (as TCP and many other 
popular fairness mechanisms do) has no intellectual heritage from any 
concept of fairness in philosophy or social science, or indeed real life. 
Comparing and controlling flow rates alone will never achieve fairness and 
should never again be claimed as a fairness mechanism for production 
networks. Instead, a realistic fairness mechanism must share out the `cost' 
of each users actions on others.

>    TCP within an order of magnitude.

Bandwidth consumption is nothing to do with fairness. The issue is how much 
congestion is caused.

>One method of determining an

The above draft explains, using TFRC as an example at one point, how we've 
all been barking up the wrong tree for the last couple of decades.

Using this new-found understanding, a pseudo-wire with a different 
congestion response to TCP's should restrict how much congestion it causes 
(ie the byte volume of loss), not how much rate it gets.

Cheers

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196