Re: [tcpm] Accurate ECN side-meeting

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 (tcpm@ietf.org); Yu-Shun Wang
Subject: RE: [tcpm] Accurate ECN side-meeting

Some dumb questions:
1. is tcpm the right place for that? if not is there a better one?

[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

>
>
>
> Thanks
>
> Murari
>
>
>
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf 
> Of Scheffenegger, Richard
> Sent: Monday, July 30, 2012 1:33 PM
> To: tcpm (tcpm@ietf.org)
> Subject: [tcpm] Accurate ECN side-meeting
>
>
>
> 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
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>