Subject: [tcpm] Accurate ECN side-meeting

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 30 Jul 2012 20:32:41 +0000

Hi,

Since there was virtually no time for discussion today in the TCPM meeting, who would be interested in (and have time for) a side meeting to discuss further on the Accurate ECN topic?

For me, it became apparent that the problems and requirements statement are not too well understood so far (and I'm not excluding myself).

Currently, we have feedback with perfect Reliability (getting one signal per RTT, with a simple handshake mechanism).

Ack loss (or delayed ACKs with more than than 2 data packets) presents another problem,...

I think Matt has a very valid point that the solution space needs more discussions, ideally from more participants than only between the authors!

Richard Scheffenegger

---

From: Murari Sridharan <[email-masked]>
Date: Mon, 30 Jul 2012 22:58:51 +0000

I think this is an important topic that deserves more discussion. I unfortunately couldn't make it to Vancouver. Appreciate if you can forward notes from your side meeting to the list. Personally I am interested as this applies to DCTCP and if we have to take it from datacenter to Internet then this becomes critical to understand and solve.

Thanks
Murari

From: [email-masked] [mailto:[email-masked]] On Behalf Of Scheffenegger, Richard
Sent: Monday, July 30, 2012 1:33 PM
To: tcpm ([email-masked])
Subject: [tcpm] Accurate ECN side-meeting

Hi,

Richard Scheffenegger

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 30 Jul 2012 18:08:03 -0700

On Mon, Jul 30, 2012 at 3:58 PM, Murari Sridharan <[email-masked]> wrote:
> I think this is an important topic that deserves more discussion. I
> unfortunately couldn’t make it to Vancouver. Appreciate if you can forward
> notes from your side meeting to the list. Personally I am interested as this
> applies to DCTCP and if we have to take it from datacenter to Internet then
> this becomes critical to understand and solve.
My observation is that the interests to improve ECN is high. Bob likes
DCTCP, Matt likes better ECN and encourage Mirja's works.

Some dumb questions:
1. is tcpm the right place for that? if not is there a better one?
2. any real data on the "I"internet to justify the current ECN RFC is
not good enough and need improvement. NOTE: I want to see data, not
theories.
3. will a better ECN motivate rapid deployment.

> Since there was virtually no time for discussion today in the TCPM meeting,
> who would be interested in (and have time for) a side meeting to discuss
> further on the Accurate ECN topic?
>
>
>
>
>
> For me, it became apparent that the problems and requirements statement are
> not too well understood so far (and I’m not excluding myself).
>
>
>
> Ack loss (or delayed ACKs with more than than 2 data packets) presents
> another problem,…
>
>
>
>
>
>
>
> I think Matt has a very valid point that the solution space needs more
> discussions, ideally from more participants than only between the authors!
>
>
>
>
>
>
>
> Richard Scheffenegger
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 30 Jul 2012 21:37:44 -0400

> 1. is tcpm the right place for that? if not is there a better one?

I think it's the right place, with responsible AD hat on :)

-- 
Wes Eddy
MTI Systems

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 31 Jul 2012 05:25:30 +0000

> 2. any real data on the "I"internet to justify the current ECN RFC is not
> good enough and need improvement. NOTE: I want to see data, not theories.

Well, since the Internet at large doesn't run ECN, what kind of data would there be?

DCTCP which reacts to the extent of congestion in a different way than standard TCP, while not penalizing it with long standing queues, appears to be quite a solid data point that ECN can be made to work... But current 3168 ECN is to restrictive for that application...

> 3. will a better ECN motivate rapid deployment.

ECN on itself probably not; so far, the inventives have not been high enough. However, as Bob pointed out (well, I'm paraphrasing), with the convergence of CoDel and Bufferbloat and DCTCP, it seems there is currently a window of opportunity to address the open signaling topics that would work best in the internet and with these new protocols, not? After all, a new ECN signaling scheme (actually a TCP ECN feedback scheme) needs deployment with new stacks, that run new mechanisms making use of that additional information...

Best regards,

Richard Scheffenegger

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 31 Jul 2012 18:59:29 +0000

Some dumb questions:

[MS] I believe so. 

2. any real data on the "I"internet to justify the current ECN RFC is not good enough and need improvement. NOTE: I want to see data, not theories.
[MS] ECN isn't widely deployed to start with. Secondly the problem here is quite obvious which is the way the ECN marks are echoed by the receiver and used by the source. Unless you fix both you cannot hope to get full link utilization. You could split this into two problems one is what Richard and Mirja have taken up which is how do you reflect back accurate ECN feedback and DCTCP provides one example of how sources can use those marks to average and pick a rate to transmit. 

3. will a better ECN motivate rapid deployment.
[MS] Personally my reasons for lack of ECN deployment are as follows, in no specific order, a) used to be chicken and egg problem between OS vendors and network operators for the longest time. Then OS vendors did implement fully ECN capability b) then we started finding crappy implementations of ECN, WS in home gateways that made ECN not be default c) RED is hard to configure and get right. d) Standard TCP's use of ECN the point above about 3168 and way sources were reacting to it casues a loss of link utilization. 

To really solve the problem of simultaneously catering to throughput sensitive and latency sensitive flows we need accurate ECN feedback. I also think we have a real opportunity to move away from complex AQMs to something much simpler and let the sources (E2E design) handle the RTT smoothing. No matter how you slice and dice it AQMs of today including CoDel are forced to pick parameters (even if they are hardcoded) that don't translate across networks and have to be arbitrarily chosen. 

Thanks

> Since there was virtually no time for discussion today in the TCPM 
> meeting, who would be interested in (and have time for) a side meeting 
> to discuss further on the Accurate ECN topic?
>
>
>
>
>
> For me, it became apparent that the problems and requirements 
> statement are not too well understood so far (and I'm not excluding myself).
>
>
>
> Currently, we have feedback with perfect Reliability (getting one 
> signal per RTT, with a simple handshake mechanism).
>
>
>
> another problem,...

---

From: Murari Sridharan <[email-masked]>
Date: Tue, 31 Jul 2012 19:10:28 +0000

In fact I'd go as far as to say "how to get TCP to consume significantly less buffers to achieve the same throughput" is one of the most important problems for TCPM to solve. Without this folks are going to do brute force workarounds to try and lower the latency for everybody else on the network. The discussion around congestion control RTCWeb at the recent workshop is a great example. If we don't fix TCP on the Internet everything else (protocols, hardware) will have to become more complex (and less resilient) just to work around this problem. 

IMHO the starting point for all of this is to get ECN enabled on the Internet. It requires the kind of effort and drive that IETF is putting behind IPv6. 

Thanks

-----Original Message-----
From: Murari Sridharan 
Sent: Tuesday, July 31, 2012 12:00 PM
To: 'Yuchung Cheng'
Cc: Scheffenegger, Richard; tcpm ([email-masked]); Yu-Shun Wang
Subject: RE: [tcpm] Accurate ECN side-meeting

Some dumb questions:

[MS] I believe so. 

Thanks