Subject: Re:Re: MPLS - ATM interworking?

From: "Andrzej Czerczak" <Andrzej_Czerczak/[email-masked]>
Date: Wed, 31 May 2000 19:33:13 +0200

Robert,
First of all thanks for your comments.

>Have you read draft MPLS Support of Differentiated Services
>draft-ietf-mpls-diff-ext-04.txt where we are proposing to use the ECN
>(explicit congestion notification) on a per LSP basis using the EXP bits
>in the shim header ? Currently this is the most attractive option, but I
> am not aware of any implementation support this today.

a) Document draft-ietf-mpls-diff-ext-04.txt does not not define the usage
of ECN.

b) Taking into account label merging capabilites of LSRs, how can determine
to which ingress LSP to to send Congestion Notification?

c) Where can I find:

Ramakrishnan et al., "A Proposal to Incorporate ECN in
   MPLS", draft-ietf-mpls-ecn-00.txt?

What I'd like to say is, that at least during first phases of
implementations (before entire infrastructure will become IP) interworking
of MPLS core and ATM edge will be important, but I could not find a
proposal of how to do interworking between them.

Andrzej

---

From: "Andrzej Czerczak" <Andrzej_Czerczak/[email-masked]>
Date: Wed, 31 May 2000 19:46:01 +0200

Robert,

c) Where can I find:

Andrzej

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 May 2000 11:33:49 -0700

Andrzej,

1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is attached to
this email.

2)Congestion Notification is and end-to-end signal which is meant to be used
by TCP. You don't need to know the ingress LSR or even the LSP from which
the congested packet is received. The receiver may send the congestion
notification to the sender using source IP address, either through another
LSP or even through normal IP hop-by-hop routing.

Regards,
-Shahram

>-----Original Message-----
>From: Andrzej Czerczak [mailto:Andrzej_Czerczak/[email-masked]]
>Sent: Wednesday, May 31, 2000 1:46 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re:Re: MPLS - ATM interworking?
>
>
>
>Robert,

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 May 2000 12:49:43 -0700

Hi,
 
1) Please check RFC 2481 for the definition and usage of ECN. 
2) As far as I know there is currently no proposal to use ECN bits in an
Edge-to-Edge level. The intention of Sally Floyd's draft was that ECN to be
used with TCP (end-to-end). 
 
Regards,
Shahram

-----Original Message-----
From: CATANZARITI Sergio FTR&D/TI
[mailto:[email-masked]]
Sent: Wednesday, May 31, 2000 3:13 PM
To: 'Shahram Davari'
Cc: [email-masked]; 'Andrzej Czerczak'; [email-masked]
Subject: RE: Re: MPLS - ATM interworking?

Shahram, 

	the draft-ietf-mpls-ecn-00.txt does not say anything about ECN usage
and applications, but only about ECN support and definition in an MPLS
network, the things are quite different. So, I have the same question: where
I can find Ramakrishnan et al., "A Proposal to Incorporate ECN in MPLS",
draft-ietf-mpls-ecn-00.txt?

	Also, I do believe that the ECN in an MPLS network works on resource
types (LSPs) quite different than native IP flows. So, the source address is
not that useful here, albeit in an ECN schema in pure IP networks.

	ECN in an MPLS network is supposed to signal congestion in an
edge-to-edge fashion (different from end-to-end) where the LERs could
cooperate on that.

	Absolutely, I want to associate LSPs with congestion dynamics to
eventually slow them down. How can I do that? That's the question.

Sergio 

	--------------------------------------------------------------------

Sergio Catanzariti 
Senior Project Manager, Technology Integration 
France Telecom R&D 
1000 Marina Boulevard Suite 300 
Brisbane CA 94005 
Tel. 650-875-1526 
Fax. 650-875-1505 
email:[email-masked] 
-------------------------------------------------------------------- 

	-----Original Message----- 
From:   Shahram Davari [SMTP:[email-masked]] 
Sent:   Wednesday, May 31, 2000 11:34 AM 
To:     'Andrzej Czerczak'; [email-masked] 
Cc:     [email-masked] 
Subject:        RE: Re: MPLS - ATM interworking? 

	Andrzej, 

	1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which is
attached to 
this email. 

	2)Congestion Notification is and end-to-end signal which is meant to
be used 

	Regards, 
-Shahram 

>From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/[email-masked]
<mailto:Andrzej_Czerczak/[email-masked]> ] 

>proposal of how to do interworking between them. 
 << File: draft-mpls-ecn-00.txt >>

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Wed, 31 May 2000 13:01:23 -0700

Thanks, I knew that RFC. But, it does not solve the original question that
was ECN application in an MPLS network and its usage.

Sergio

> Sent:	Wednesday, May 31, 2000 12:50 PM
> To:	'CATANZARITI Sergio FTR&D/TI'; Shahram Davari

---

From: Shahram Davari <[email-masked]>
Date: Wed, 31 May 2000 14:03:36 -0700

Hi,
 
As I said there is currently no ECN application in MPLS networks, rather
there is ECN processing in MPLS networks for TCP applications. 
 
I think you agree that ECN is useful because it can control congestion
without dropping packets, which leads to higher BW utilization (i.e., does
not waste BW with the packets which are dropped). This goal is achieved  by
reducing the TCP transmission window. 
 
If I understand correctly, what you are proposing is that an ingress LSR may
be able to use the ECN notification to divert some of the traffic to other
LSPs (i.e., balance the load across multiple LSPs), which leads also to
higher BW utilization. In other words ECN notification may be as an input to
the Constraint-Based routing algorithm, which runs on the ingress LSRs. 
 
However, the same objective can be achieved by feeding back the current
congestion status information in LSRs to the ingress LSRs, using the LSP
feedback mechanism (check out section 7 of
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt).
<http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt)>  , or
even with extensions to IGPs. Using this mechanism you won't need the ECN
bits and ECN notification for the edge-to-edge congestion control, because
the congestion information is available locally on each LSR and the
feed-back is also generated locally.
 
Does this answer your question?
 
Regards,
-Shahram

 

[Shahram Davari] 
 -----Original Message-----
Sent: Wednesday, May 31, 2000 4:01 PM

Sergio 

Sergio Catanzariti 

	-----Original Message----- 
From:   Shahram Davari [SMTP:[email-masked]] 
Sent:   Wednesday, May 31, 2000 12:50 PM 
To:     'CATANZARITI Sergio FTR&D/TI'; Shahram Davari 
Cc:     [email-masked]; 'Andrzej Czerczak'; [email-masked] 
Subject:        RE: Re: MPLS - ATM interworking? 

	Hi, 

Regards, 
Shahram 

	-----Original Message----- 
From: CATANZARITI Sergio FTR&D/TI 
[ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, May 31, 2000 3:13 PM 
To: 'Shahram Davari' 
Cc: [email-masked]; 'Andrzej Czerczak'; [email-masked] 
Subject: RE: Re: MPLS - ATM interworking? 

	Shahram, 

	        the draft-ietf-mpls-ecn-00.txt does not say anything about
ECN usage 
and applications, but only about ECN support and definition in an MPLS 
network, the things are quite different. So, I have the same question: where

	        Also, I do believe that the ECN in an MPLS network works on
resource 
types (LSPs) quite different than native IP flows. So, the source address is

	        ECN in an MPLS network is supposed to signal congestion in
an 
edge-to-edge fashion (different from end-to-end) where the LERs could 
cooperate on that. 

	        Absolutely, I want to associate LSPs with congestion
dynamics to 
eventually slow them down. How can I do that? That's the question. 

	Sergio 

	Sergio Catanzariti 

	        -----Original Message----- 
From:   Shahram Davari [SMTP:[email-masked]] 
Sent:   Wednesday, May 31, 2000 11:34 AM 
To:     'Andrzej Czerczak'; [email-masked] 
Cc:     [email-masked] 
Subject:        RE: Re: MPLS - ATM interworking? 

	        Andrzej, 

	        1)ECN usage is defined in draft-ietf-mpls-ecn-00.txt, which
is 
attached to 
this email. 

	        2)Congestion Notification is and end-to-end signal which is
meant to 
be used 

	        Regards, 
-Shahram 

>From: Andrzej Czerczak [ mailto:Andrzej_Czerczak/[email-masked]
<mailto:Andrzej_Czerczak/[email-masked]>  
< mailto:Andrzej_Czerczak/[email-masked]
<mailto:Andrzej_Czerczak/[email-masked]> > ]

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Wed, 31 May 2000 14:37:27 -0700

>there is ECN processing in MPLS networks for TCP applications. 

Oh, thank you. I wanted just to be reassured about that, so there is no ECN
value add unique to MPLS that we already do not know for pure IP networks,
with all the related ECN debates (TCP misbehavior, UDP-based multimedia
flows independence)

	> reducing the TCP transmission window. 

	Sure. It is that I have still difficulty to see the relationship
between TCP flows and LSPs aggregates, but that is my problem not yours.

	>Using this mechanism you won't need the ECN

Thanks for having pointed it out. That is where I am more interested as LSPs
provider. 

Regards,
Sergio

> Sent:	Wednesday, May 31, 2000 2:04 PM

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Wed, 31 May 2000 14:53:06 -0700

Curtis,

	>ECN != ABR
	>ECN != EFCI

	Really? I thought they were the same thing. It is my fault, I should
have continued my education, instead of dropping out at the elementary
school and play soccer :-)

	Seriously, I believe that the ABR difficulties were related to the
fact that it was an end-to-end mechanism rather than an edge-to-edge, so it
followed the destiny of native end-to-end ATM applications.
	But that is "acqua passata", let us move on.

	My only point is that as a provider I have to configure, monitor,
doing something with my Lisps-based ECN bits at my edge router, without
giving me any possibility to act on that, and that does not sound very
appealing to me. To an end customer (mine, I mean), that is a different
story.

	Sergio

> From:	Curtis Villamizar [SMTP:[email-masked]]
> Sent:	Wednesday, May 31, 2000 1:41 PM
> To:	CATANZARITI Sergio FTR&D/TI
> Cc:	'Shahram Davari'; [email-masked]; 'Andrzej Czerczak'; [email-masked]
> Subject:	Re: MPLS - ATM interworking? 
> 
> 
> In message
> <[email-masked]>
> , CATANZARITI Sergio FTR&D/TI writes:
> > 
> Shahram already pointed to RFC2481 and draft-ietf-mpls-ecn-00.txt but
> perhaps a brief explanation will help.
> 
> When an LSP is set up as ECN capable, the underlying traffic must be
> capable of supporting end-to-end ECN as specified in RFC2481.  This
> means the L3PID in the MPLS setup must indicate IPv4 (or IPv6, but let
> discuss IPv4 for the moment).  For each IPv4 packet arriving at the
> ingress, if the IPv4 header indicates that the packet has the ECT
> (ECN-Capable Transport) bit is set and the CE bit is not (Congestion
> Experienced), then the MPLS ECN bit is set.
> 
> If later an LSR implementing active queue management (for example RED,
> Random Early Detection) experiences congestion and would have dropped
> a packet, if the MPLS ECN bit is set, then it is cleared.  Note that
> at a second congestion point, an actual drop would occur, unlike the
> two bit scheme.  At the egress where the POP occurs, if the MPLS ECN
> bit is clear and the ECT bit is set in the underlying IP header, then
> the CE bit is set in the IP header.
> 
> Same would apply to IPv4 or any other protocol that implements a
> compatible ECN scheme (currently there are no others).
> 
> ECN != ABR
> ECN != EFCI
> There is no ABR for MPLS.  To the extent that MPLS differs from ATM,
> the differences are (mostly) intentional and IMHO ommision of an ABR
> like capability (given that ABR didn't work well in IP networks due to
> interactions between the ABR feedback loop and the TCP end-to-end
> feedback loop) is also intentional and it should stay that way.
> 
> Curtis