Re: [re-ECN] preliminary draft of problem statement- authors wanted

[<[e-mail]>]

I completely agree we need to cover all transports, not just TCP. But TCP dies still account for 80+% of traffic by volume so it is a particularly important case, hence concentrating on it in the re-ECN protocol document. The ideal situation would be to end up with re-ECN being on ALL IP traffic, regardless of transport.

The "trust issue" is actually more subtle. Users want to get the most out of the system - they want to maximise their own return. Application writers want to sell their apps to these users and will therefore incorporate anything that improves the experience of that user. The trick is to add another layer that means the overall social welfare of the system is also maximised whilst allowing the individual user to still benefit. It is our thesis that re-ECN coupled with appropriate congestion rationing (through token bucket policing of congestion rates) and using a weighted congestion controller in the end-system achieves all these aims...


> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]]
> Sent: 22 September 2009 13:49
> To: [e-mail]
> Cc: Moncaster,T,Toby,DER3 R
> Subject: Re: [re-ECN] preliminary draft of problem statement- authors
> wanted
> 
> Regarding the problem statement, I think it should not only focus on
> TCP.
> Often UDP traffic is the problem with "heavy usage". Re-ECN is focusing
> mainly (so far) on TCP but congestion exposure in general is not
> protocol
> dependent. Having a system which requires congestion information for
> rate
> limiting there needs to be some (negative) impact on flows which not
> reveal
> this information (as proposed with the Re-ECN framework).
> 
> Then talking about trust I don't know if it is okay to just talk about
> "users
> want to cheat the system". I think the point is that some applications
> can
> gain benefit by not being TCP-fair without any disadvantages. So there
> needs
> to be a incentive to play fair. (When you are using TCP you might have
> less
> packet loss. When you are download something it might be more important
> to be
> as fast as possible.)
> 
> Gone wait for more input by now:-)
> 
> Mirja
> 
> 
> On Friday 18 September 2009 11:57:34 [e-mail] wrote:
> >  <<draft-moncaster-congestion-exposure-problem-00.txt>> Hi All,
> >
> > Here is a very preliminary version of a Problem Statement for
> Congestion
> > Exposure. It is mainly in note form and needs MAJOR bashing. I am
> hoping by
> > posting it in this early form to persuade a few more people to
> volunteer as
> > co-authors with me...
> >
> > We need to have this in a reasonable shape by mid-October in order to
> make
> > the initial submission deadline (which is scarily close - only 4
> weeks and
> > 4 days away).
> >
> > Absolutely everything in the document is fair game for change
> including
> > title, draft name, table of content, content, ...
> >
> > Toby
> > ___________________________________________________________________
> > Toby Moncaster, <[e-mail]> Networks Research Centre, BT
> > B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
> 
> 
> 
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
> 
> web: www.ikr.uni-stuttgart.de
> email: [e-mail]
> tel: [phone]
> -------------------------------------------------------------------