Subject: [re-ECN] CONEX IESG comments #2

From: Lars Eggert <[email-masked]>
Date: Mon, 1 Mar 2010 07:33:41 -0800

Hi, CONEX group,

I'm going to forward a few issues that were raised during the IESG discussion of the charter to the list, and CC the IESG so that the discussion can happen directly, without me being the bottleneck in the middle.

(I'd like to thank the ADs who wrote up their issues in this way - this will make it much easier to progress the discussion!)

Lars

Begin forwarded message:
> The charter says:
> 
> "With the output of CONEX, it will be possible to provide sufficient 
> information in each IP datagram so that any node in the network can see 
> the expected rest-of-path congestion."
> 
> With the scope that I heard on the call which was operation at the 
> provider level, and the suggestion from Jari that this might be applied 
> to PWE3,  the issue of how to make this work in MPLS has to addressed. 
> Indeed If the goal is operation at the SP level and PWE3, failure to 
> find an acceptable MPLS solution would be a showstopper.
> 
> However if the goal is only to provide a solution that operates at parts 
> of the network where the packet  is visible as IP and this is clearly 
> stated in the requirements then the work has some merit as an experiment.
> 
> I agree with Adrian that this work looks experimental and really ought 
> to be an IRTF project, and only when it has been shown to work correctly 
> in an experimental environment should we do the heavy weight engineering 
> needed to make this a robust protocol suitable for deployment in the 
> operational Internet.

---

From: <[email-masked]>
Date: Wed, 3 Mar 2010 18:41:23 -0000

Thanks for your commets and also in Comments #1.

We think the best thing is if we work on the mailing list to put
together a consolidated reply to the comments, which we will then send
to the iesg. Hopefully a good timing for this would be over the next 2
weeks, ie reply before the ietf.

Thanks
Phil & Leslie

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: 01 March 2010 15:34
> To: [email-masked] list
> Cc: The IESG
> Subject: [re-ECN] CONEX IESG comments #2
> 
> 
> Hi, CONEX group,
> 
> I'm going to forward a few issues that were raised during the 
> IESG discussion of the charter to the list, and CC the IESG 
> so that the discussion can happen directly, without me being 
> the bottleneck in the middle.
> 
> (I'd like to thank the ADs who wrote up their issues in this 
> way - this will make it much easier to progress the discussion!)
> 
> Lars
> 
> Begin forwarded message:
> > The charter says:
> >

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 09 Mar 2010 10:45:24 +0000

Phil, Leslie,

Perhaps now the I-D deadline has past we'll see some discussion of 
the IESG comments #1 (I posted a few days ago).
In the meantime, here's my suggested response to IESG comments #2, inline...

At 15:33 01/03/2010, Lars Eggert wrote:
>Hi, CONEX group,
>
>I'm going to forward a few issues that were raised during the IESG 
>discussion of the charter to the list, and CC the IESG so that the 
>discussion can happen directly, without me being the bottleneck in the middle.
>
>(I'd like to thank the ADs who wrote up their issues in this way - 
>this will make it much easier to progress the discussion!)
>
>Lars
>
>Begin forwarded message:
> > The charter says:
> >

To be concrete I will only talk about the specific protocol, re-ECN, 
as a candidate ConEx protocol.

Re-ECN was designed to ensure the sender exposes congestion from any 
lower layer forwarding element not just IP. It was also designed to 
expose congestion whether that congestion exhibits as drop or as 
explicit markings. However, if a network wants to precisely and 
quickly detect that packets are under-declaring congestion, its best 
strategy will be to ensure that congested forwarding elements can 
notify congestion explicitly.

If congestion could be at MPLS nodes, integrity checking of re-ECN 
signals has been designed to be precise if the switches comply with 
RFC5129, which specifies both ECN marking at a label switch and 
propagation of those markings up the layers to IP.

There will always be nodes on the path that do not support ECN, and 
only drop packets when congested. The re-ECN protocol specifies that 
the source must declare these congestion events by re-inserting 
congestion feedback into the network. If support for re-ECN is 
implemented in the network stack of the host, it would be difficult 
but not impossible for an attacker to make the transport 
under-declare the presence of drops. A network concerned about such 
cheating can prevent it by deploying explicit congestion notification 
at potential points of congestion and deploying policing elements 
like those described in outline in 
draft-briscoe-tsvwg-re-ecn-tcp-motivation. The latest policer designs 
(reviewed but to appear) mitigate congestion from DDoS and a range of 
malicious attacks on the system.

More details:
------------
Re-ECN involves two congestion notification signals in the IP header:
* expected congestion (whole path) inserted by the source and immutable
* actual congestion so far (upstream path), introduced into the outer 
header by congested forwarding elements (routers, switches).
The full benefits of re-ECN quoted in the charter come from being 
able to subtract the latter from the former to measure downstream 
congestion at any IP node.

While a packet is traversing a lower-layer network that supports ECN, 
only the actual congestion field will be visible in the outer header, 
while the expected congestion field will be buried in an encapsulated 
IP header. Whenever the IP header is decapsulated at an IP node, it 
will be possible to see both.

The uses proposed so far for re-ECN are only relevant at trust 
boundaries, either customer-network or network-network. Although 
there are some proposals to operate MPLS across trust boundaries 
without coming up to the IP layer, the design of re-ECN was on the 
basis that IP is considered the protocol for inter-networking. If 
networks wish to use MPLS as an internetworking protocol, it can only 
be assumed they have their own trust relationship or bespoke trust 
mechanisms in place.

> > needed to make this a robust protocol suitable for deployment in the

As in response to comment #1: Experimental track: yes. But that 
doesn't mean IRTF. It has been researched to death already.

It may not be appreciated that re-ECN requires no changes to IETF 
data plane standards.

HTH

Bob

>_______________________________________________
>re-ECN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Tue, 16 Mar 2010 10:24:04 -0000

In-line
Best wishes
phil

> > needed to make this a robust protocol suitable for 

Yes, the intention is for a solution that operates where the packet is
visible as IP. More precisely, rest-of-path (& whole path) congestion is
only visible where the packet is IP; congestion info can be set where
the packet is MPLS using rfc5129.

---

From: <[email-masked]>
Date: Wed, 17 Mar 2010 09:34:28 -0000

Hi,

We need to put together a consolidated reply to the iesg comments.
Please send any more comments today; then Leslie & I will do the
consolidation

thanks

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 03 March 2010 18:41
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [re-ECN] CONEX IESG comments #2
> 
> 
> We think the best thing is if we work on the mailing list to 
> put together a consolidated reply to the comments, which we 
> will then send to the iesg. Hopefully a good timing for this 
> would be over the next 2 weeks, ie reply before the ietf.
> 
> Thanks
> Phil & Leslie
>