Subject: [PWE3] QoS vs. Congestion Control

From: [email-masked]
Date: Wed, 16 Nov 2005 18:09:48 -0500

Craig,

NB: New subject line

> When this working group was chartered we spent a lot of time 
> coming to grips with the fact that pwe3 will make certain 
> requirements of a PSN. Hopefully this work was captured in 
> RFC 3916 - Requirements for Pseudo-Wire Emulation 
> Edge-to-Edge (PWE3), mainly sections 7, 8 and 9. 
>  
> For example in section 9, 
>  
>    "QoS is therefore essential for
>    ensuring that emulated services are compatible (but not necessarily
>    identical) to their native forms.  It is up to network operators to
>    decide how to provide QoS - They can choose to rely on over-
>    provisioning and/or deploy some QoS mechanisms."
>  
> And also,
>  
> "These mechanisms do not
>    have to be defined in the PWE3 approaches themselves.  For example,
>    if the resulted packets are MPLS or IP packets, their EXP or DSCP
>    field can be used for marking and differentiating.  A PWE3 approach
>    MAY provide guidelines for marking and differentiating."

Quality of Service (QoS) and congestion control are separate topics/issues.
For example, TCP implementations MUST perform congestion control even
when connected to networks that have no better-than-best-effort QoS
mechanisms whatsoever in the network, as failure to do so risks congestive
collapse (see RFC 2914).  If RFC 3916 places QoS out of scope for pseudo-
wires, that does not affect requirements to provide TCP-class congestion
control for pseudo-wires whose traffic may compete with TCP traffic in
networks subject to congestion.

At the risk of getting myself into serious trouble, does/should this issue
be applied to other encapsulations?  At least for ATM and Ethernet I
would be comfortable with a view that the PW provides a best-effort service
(ATM or Ethernet) on top of a best-effort service, and hence congestion
control is the responsibility of higher layers in the stack as would be
the case absence of the PW.  QoS may obviate the need for congestion
control, but this cannot be relied upon in all situations.  In contrast,
FC differs from ATM and Ethernet in that in its current state, there's
nothing at higher layers in FC that supports the sort of congestion
control required in unconstrained best-effort networks, and hence
something has to be done.

Sorry,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "Craig White" <[email-masked]>
Date: Thu, 17 Nov 2005 08:29:58 -0800

It was not my intention to discuss the *many* ways pseudo wires are
different from other services. I simply wanted to point out that surely
the requirements document took the special requirements of this service
into account. 

Many people feel, just as Stewart mentioned in his email, that these
services may not perform acceptably over the Internet. It is up to the
user of the service to ensure that the target network(s) can support the
intended service. 

As far as congestion control (and other (X)oS's), can we agree on this
one point, if you have no packet loss and no (very low) packet delay
jitter (ie., delay is only the speed of light factor X distance, not
chronic buffering), then you will not have congestion?

"Bandwidth has qualities all its own..."

It is quite possible that if things in the network break, the games off
and the service will not work.

Are you suggesting that we need to go back and amend the requirements
document in order to work on this draft in this working group? Or do we
just shut down because our work may not be TCP friendly any sooner than
many other protocols?

BTW: While I do support this draft becoming a working group document,
I'm most concerned with its MPLS focus, rather than the lack of
congestion control, and the need for a well engineered network, etc. I
thought a pseudo wire encap was meant to be agnostic and should run over
IP also, but I see reference to an existing standard that does this in
the draft.

-craig

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2005 6:10 PM
To: Craig White; [email-masked]
Subject: QoS vs. Congestion Control

Craig,

NB: New subject line

>    MAY provide guidelines for marking and differentiating."

Quality of Service (QoS) and congestion control are separate
topics/issues.
For example, TCP implementations MUST perform congestion control even
when connected to networks that have no better-than-best-effort QoS
mechanisms whatsoever in the network, as failure to do so risks
congestive
collapse (see RFC 2914).  If RFC 3916 places QoS out of scope for
pseudo-
wires, that does not affect requirements to provide TCP-class congestion
control for pseudo-wires whose traffic may compete with TCP traffic in
networks subject to congestion.

At the risk of getting myself into serious trouble, does/should this
issue
would be comfortable with a view that the PW provides a best-effort
service

Sorry,
--David

---

From: [email-masked]
Date: Thu, 17 Nov 2005 14:53:17 -0500

Craig,

> the requirements document took the special requirements of this service

That conclusion is not correct for congestion control because:
- Congestion control is not QoS.  Congestion control is necessary even
	when no QoS measures are used.  At the risk of sounding like
	a broken record, see RFC 2914.
- The word "congestion" does not occur in RFC 3916, not even once.

IMHO, a better summary of the situation is that RFC 3916 has no
impact on congestion control requirements and responsibilities, which
are generally dealt with at protocol layers above the protocols intended
for direct pseudo-wire encapsulation.

> user of the service to ensure that the target network(s) can 
> support the intended service.

I agree with latter sentence - there's no substitute for competent
network (traffic) engineering.

> "Bandwidth has qualities all its own..."

Yes, provided that sufficient attention is paid to the *if* in the
above text.  I have no problem with applicability text in a PW
draft that recommends use of that specific PW encapsulation only
under  provisioning that ensures no packet loss, low jitter, and
whatever else is needed.  OTOH, I see no reason to inflict that on
the Ethernet PW encapsulation.

> and the service will not work.

That is generally true for almost all networks and services.

> document in order to work on this draft in this working group?

I would hope that's not necessary, as I wrote earlier in this thread:

>> At least for ATM and Ethernet I
service
>> the case [in the] absence of the PW.

In general, I think congestion can be considered on a per-PW-encap basis
as part of discussing applicability.

> Or do we just shut down because our work may not be TCP friendly any
sooner
> than many other protocols?

Don't be ridiculous - I assume the :-) :-)'s were inadvertently omitted
from that question.

Thanks,
--David

> From: Craig White [mailto:[email-masked]] 
> Sent: Thursday, November 17, 2005 11:30 AM
> To: Black, David; [email-masked]
> Subject: RE: QoS vs. Congestion Control
> 
> user of the service to ensure that the target network(s) can 
> support the > intended service. 
> 
topics/issues.
service