Subject: [PWE3] Congestion Text for the frame relay encapsulation draft.

From: Luca Martini <[email-masked]>
Date: Mon, 13 Feb 2006 14:09:18 -0700

WG,

Below is the section  that I would like to add to the frame relay 
encapsulation draft. This text is required to satisfy an IESG request 
made about other similar PWE3 documents  to have an explanation  of how 
a PW should behave if the PSN becomes congested.
This text is similar to the text in the PPP/HDLC draft , however I have 
added some frame relay specific notes.
Since with frame relay we can actually notify  the head end frame relay 
device of the congestion situation I thought it could be useful to 
mention it.

Please send me any comments/suggestion that you may have.
Thanks.
Luca

.Pa "Congestion Control"
As explained in [ARCH], the PSN carrying the PW may be subject to
congestion, with congestion characteristics depending on PSN type, network
architecture, configuration, and loading. During congestion the PSN may
exhibit packet loss that will impact the service carried by the frame relay
PW. In addition, since frame relay PWs carry an unspecified type of services
across the PSN, they cannot behave in a TCP-friendly manner prescribed by
[RFC2914]. In the presence of services that reduce transmission rate, frame
relay PWs will thus consume more than their fair share and SHOULD be halted.

Whenever possible, frame relay PWs should be run over traffic-engineered
PSNs providing bandwidth allocation and admission control mechanisms.
IntServ-enabled domains providing the Guaranteed Service (GS) or
DiffServ-enabled domains using EF (expedited forwarding) are examples of
traffic-engineered PSNs. Such PSNs will minimize loss and delay while
providing some degree of isolation of the frame relay PW's effects from
neighboring streams.

The PEs SHOULD monitor for congestion (by using explicit congestion
notification, [VCCV], or by measuring packet loss) in order to ensure that
the service using the frame relay PW may be maintained. When a PE detects
significant congestion while receiving the PW PDUs, the BECN bits of the
frame relay frame transmitted on the same PW SHOULD be set to notify the
remote PE, and the remote frame relay switch of the congestion situation.

If the PW has been set up using the protocol defined in [CONTROL],
then procedures specified in [CONTROL] for status notification can be used
to disable packet transmission on the ingress PE from the egress PE. The PW
may be restarted by manual intervention, or by automatic means after an
appropriate waiting time.

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 13 Feb 2006 17:49:13 -0500

Luca,

In the second paragraph, if the CIR of a Frame Relay VC is zero, then 
it is equivalent to a best-effort UDP over IP stream regarding 
congestion - the network is free to drop frames as necessary.  The 
"DF" PHB would be appropriate in a diff-serv-TE domain.

If the CIR of a Frame Relay VC is nonzero and the DE bit is zero in 
the FR header, then I would suggest that "AF31" would be more 
appropriate than "EF" in a diff-serv-TE domain.

If the CIR of a Frame Relay VC is nonzero, but the DE bit is on, then 
"AF32" would be an appropriate marking.

These PHBs follow the general guidelines that zero-CIR FR is 
generally mapped to the ATM service class UBR, while non-zero-CIR FR 
is mapped to the ATM service class VBR-nrt, which is itself generally 
mapped to AF31 or AF32 depending on the ATM CLP bit.  This also 
follows the mappings between the FR DE bit and PHBs in RFC 3270.

In the third paragraph, I would also specify that when congestion is 
detected  by the PE receiving FR frames from the pseudowire, the FECN 
bit SHOULD be set in the FR frames sent out the attachment circuit, 
to give the FR DTE a chance to adjust its transport layer advertised 
window if possible.

Finally, since IP is the most popular application that runs over FR, 
and TCP flows over FR will adjust to consume their fair share, I 
would revise the first paragraph as follows:

As explained in [ARCH], the PSN carrying the PW may be subject to
congestion, with congestion characteristics depending on PSN type,
network architecture, configuration, and loading. During congestion
the PSN may exhibit packet loss that will impact the service carried
by the frame relay PW. In addition, since frame relay PWs carry an
variety of services across the PSN, including but not restricted  to
TCP/IP, they may or may not behave in a TCP-friendly manner prescribed
by [RFC2914]. In the presence of services that reduce transmission
rate, frame relay PWs may thus consume more than their fair share and
in that case SHOULD be halted.

Thanks,
Andy

At 2/13/2006 14:09 -0700, Luca Martini wrote:
>encapsulation draft. This text is required to satisfy an IESG 
>request made about other similar PWE3 documents  to have an 
>explanation  of how a PW should behave if the PSN becomes congested.
>This text is similar to the text in the PPP/HDLC draft , however I 
>have added some frame relay specific notes.
>Since with frame relay we can actually notify  the head end frame 
>relay device of the congestion situation I thought it could be 
>useful to mention it.
>