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

["Yaakov Stein" <yaakov_s at rad.com>]

> Folks,
> Please consider today the start of a two-week WG LC for this document.

Stewart et al.

I apologize for just getting around to reading this document.

I have so many issues with it, that I don't know where to begin.

So I guess I will start with the scope. 
The draft claims to address congestion control for PWs. 
Actually it addresses TCP friendliness for PWs over the Internet
(or an Internet-like environment).
This preassumes that the most interesting topic to be solved
is how to keep PWs from crashing the Internet.
I have no doubt that this is an important issue,
since if we produce an encapsulation, then someone may one day use it on
the public Internet.
However, there is still a major jump between this legitimate concern 
and calling the treating of this pathological case "congestion control
for PWs".

Setting aside the aforementioned unusual cases, the focus of PWE3 is,
and has always been,
the service provider environment. No SP I have ever seen would place
individual user TCP flows
inside an MPLS tunnel along with PWs. And if one did, then they would
certainly have no problem
with such an individual user flow suffering from the PW traffic - and
would certainly not reduce
the PW service level in order to protect such an individual TCP flow.
(Note - I am not including
system TCP flows, such as LDP or BGP here. These would assumably be
appropriately prioritized).

So, I would have much fewer problems with calling this ID "congestion
control for PWs over the Internet",
but definitely object to calling it "congestion control for PWs".

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.

What should a congestion framework for a service provider network
specify ?
We should be able to enable the PWs to be guaranteed their CR, and to
enjoy excess traffic
when BW is available. When congestion occurs, we should be able to tell
the ingress PEs
that this is the case, and that they should police to their CR. If
congestion continues,
we should exercise fairness between the PWs - BUT this does NOT mean
that all PWs should
get the same BW, rather that the percentage reduction from CR should be
the same !

There are many ways that this can be done. Of course, SP networks
usually have central management,
and the management may directly instruct ingress PEs as to their
constraints.
However, we can also develop noncentralized mechanisms. In order to
obtain
the kind of fairness required, we still us AIMD, but instead of reducing
the flow to half the PRESENT
rate, we need to multiply it by a percentage of the CR (or whatever we
desire to call it here).

Second topic.
The tutorial material on TCP congestion control and TFRP are useful, 
but I believe that they miss the main point for PWs.
TCP flows end up approximately equally sharing the BW (rather than the
fairness I defined above)
because of the basic assumptions of the model, not solely because of
AIMD. 
Each TCP flow is assumed to be atomic, 
all flows are assume equally important (i.e. to have the same CR), 
and the TCP flows are assumed to emanate from an end-user box where the
back-pressure 
can be used to hold up the application.
It is this set of assumptions along with the AIMD mechanisn that leads
to the TCP rate equation.
Were an Ethernet PW carrying TCP/IP to be in parallel to TCP flows, 
then loss of a single PW packet would translate to loss of a TCP packet
of a single socket pair, and thus lead to a much smaller reduction in PW
capacity
(which I assume is what the authors mean by "equivalent number of TCP
flows").
Similarly, were we to weight the flow importance, we could get different
flow rates.

On the other hand PWs emanate from PEs that can not usually perform
back-pressure 
and need to police by dropping packets. Furthermore, as stated above,
fairness does not
mean that we allot the same BW to the PWs - instead we need to allot CRs
and police to these. 
This is more direct and easier to understand and configure than the
nebulous concept
of "equivalent number of TCP flows".

Now for some shorter issues.

There is a statement about MOST (99%?) PWs carrying TCP/IP traffic.
This certainly needs qualification. I have been involved in many network
deployments
where NONE of the PWs carry TCP/IP. 

There is a statement about the possibility of sending PWs over IPsec
tunnels.
It is unclear to me what this means. IPsec is most commonly used for
TCP/IP traffic,
and thus if you use IPsec then you probably already have the behavior
you need.
On the other hand, there are PW encapsulations that use UDP/IP which
could
potentially be put in IPsec tunnels. But these are the TDM
encapsulations,
that can not fall back at all.
Finally, perhaps the ID means some new encapsulation of PW over RFC4023
over IPsec.
If so, it would be nice to have this stated, and to explain how this
works.

The drawbacks the draft mentions regarding using the sequence numbers
to detect packet drop seem artificial. Yes, misordering can masquerade
as packet drop if the delayed packet is very late. But no method is
perfect.
BTW, for TDM PWs packet arrival times can also be used as a very
senstive
mechanism to detect imminent congestion.

The draft needs a serious edit. There are numerous typos (newtork?) 
and in several places whole words seems to have dropped
(due to congestion, no doubt).

Y(J)S



_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3