[Iccrg] Re: Heresy in Minneapolis
rbriscoe@jungle.bt.co.uk (Bob Briscoe) Tue, 18 November 2008 14:16 UTC
From: rbriscoe@jungle.bt.co.uk
Date: Tue, 18 Nov 2008 14:16:33 +0000
Subject: [Iccrg] Re: Heresy in Minneapolis
In-Reply-To: <49218BEA.6030602@cse.unl.edu>
References: <389478.7272.qm@web51803.mail.re2.yahoo.com> <aa7d2c6d0804041112n411696dfo631cbc0c6aea5258@mail.gmail.com> <200804081207.m38C773V002210@bagheera.jungle.bt.co.uk> <aa7d2c6d0804081140mf2ace5chde3312a211e95d6d@mail.gmail.com> <Pine.LNX.4.64.0804132229510.31800@tesla.psc.edu> <7D592B64-1759-496A-8746-BB19118472D8@uwaterloo.ca> <Pine.LNX.4.64.0804152236370.31800@tesla.psc.edu> <200811141915.mAEJFdOY006485@bagheera.jungle.bt.co.uk> <49218BEA.6030602@cse.unl.edu>
Message-ID: <200811181425.mAIEPImk026580@bagheera.jungle.bt.co.uk>
X-Date: Tue Nov 18 14:16:33 2008
Lisong, At 15:21 17/11/2008, Lisong Xu wrote: >Bob, > >Thank for writing such an interesting and important draft! > >After reading it (quickly), it seems to me that the draft focuses on >the fairness between different users. I agree that the fairness >between different users is important. But I believe that TCP >friendliness is proposed not only for the fairness between different >users, but also for the fairness between different applications. > >So my question is while "volume accounting" helps on the fairness >between different users (e.g. single connection vs multiple >connections, active vs non-active), will it also help on the >fairness between different applications (e.g. FTP vs VoIP, >BitTorrent vs Joost)? "Problem Statement: Transport Protocols Don't have to Do Fairness" says both sides are wrong: neither TCP-friendliness nor volume accounting. Please re-read. However, that draft only describes the problem. My proposed answer to your question about interaction between apps is 'congestion-volume' accounting. This was described in another I-D that I allowed to lapse, but published in CCR: Flow Rate Fairness: Dismantling a Religion <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#rateFairDis> To fully answer your question, a further paper (posted to this list last week) describes a simple but unfamiliar token bucket mechanism that we hoped would explain better how we think about fairness when different applications interact. Policing Freedom to Use the Internet Resource Pool <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#polfree> Again, fairness here is a deeper level of fairness than flow rate. It's down deeper - at the packet level - it involves integrating mutual instantaneous congestion in all queues a user's traffic uses, over time (easily measured as 'congestion volume'). more... >By the way, we are also working on how to relax the traditional >definition of TCP-friendliness. Currently, we are focusing on the >impact of UDP-based applications on TCP-based applications. You can >find more information here http://csce.unl.edu/~xu/research/stochasticTCP.html. Yes, I already know your work. I'm afraid I don't agree. Please see S.7.3 on TFRC in the CCR paper 'Flow Rate Fairness' above. We're in the process of proving our arguments for a further paper due shortly. As flows become less responsive to congestion on short timescales (inelastic or semi-elastic), they are more likely to need to respond at flow start (admission control). This is the motivation for the new pre-congestion notification (PCN) standards, which the IETF's PCN working group is just about to publish. <http://tools.ietf.org/wg/pcn/>. Also relevant: see the minutes of yesterday's PWE3 session about their congestion framework. HTH Bob >Thanks! >Lisong > >-- >Lisong Xu, Assistant Professor >Computer Science & Engineering >University of Nebraska-Lincoln >http://cse.unl.edu/~xu > >Bob Briscoe wrote: >>Matt & I have been having a side conversation about this. >>In summary, we agree on what we don't want, but there's less >>consensus on the path ahead. >>I'd like to suggest that those interested in what the IETF needs to >>do about relaxing TCP-friendliness make sure they're around in >>ICCRG. I've bcc'd a few folks who I suspect will be interested but >>might not naturally look in on ICCRG. >>I haven't put this to the r-g chairs, but I imagine a discussion >>will start in response to Matt's talk, and might need some time to >>adjorn to a bar afterwards (there's one more session before the end >>of the day afterwards tho). Perhaps we'll get together a truly ad >>hoc Bar BoF :) >>I know Matt is also talking on this in TSVWG & TSVAREA, but I >>imagine ICCRG ought to be where any initial activity migrates to (& >>I think Matt agrees). >>My interest is that I believe TCP friendliness has become a >>self-imposed barrier to innovation. What's the point of having the >>e2e principle if you stop yourself and everyone else using the >>freedom it gives on some dodgy grounds you can't really justify? >>See "Problem Statement: Transport Protocols Don't Have To Do Fairness " >><draft-briscoe-tsvwg-relax-fairness-01.txt> >> >>Bob >> >>At 03:23 16/04/2008, Matt Mathis wrote: >>>On Tue, 15 Apr 2008, S. Keshav wrote: >>> >>>>Matt, >>>> The paradigm holds sway only in the minds of academia. I >>>> think (based almost purely on cynicism), that in the real world >>>> TCP friendliness never had a chance. There is a long history of >>>> TCP accelerators, multi-connection applications, UDP-blasters, >>>> packet classifiers-and-delayers, and who knows what else that >>>> have never cared about it. So, why do we need to phase it out? >>> >>>I would tend to agree. However, isn't this list supposed to >>>represent academia? >>> >>>>Its already a done deal. >>> >>>Not in TCPM, TSVWG, etc, where dogmatic attachment to TCP-friendly >>>is probably hurting the IETF. This is where we need to change >>>minds and some deeply entrenched documents. >>> >>>I think the ADs are probably listening - do they have any commemts? >>> >>>Thanks, >>>--MM-- >>> >>>_______________________________________________ >>>Iccrg mailing list >>>Iccrg@cs.ucl.ac.uk >>>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg >>____________________________________________________________________________ >>Bob Briscoe, <bob.briscoe@bt.com> Networks Research Centre, BT Research >>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 >>_______________________________________________ >>Iccrg mailing list >>Iccrg@cs.ucl.ac.uk >>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg > > >_______________________________________________ >Iccrg mailing list >Iccrg@cs.ucl.ac.uk >http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg ____________________________________________________________________________ Bob Briscoe, <bob.briscoe@bt.com> Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
- [Iccrg] Heresy recapped Lars Eggert
- [Iccrg] Heresy recapped Lars Eggert
- [Iccrg] Heresy recapped Lachlan Andrew
- [Iccrg] Heresy recapped Eddy, Wesley M. GRC-RCN0[VZ]
- [Iccrg] Heresy recapped Eddy, Wesley M. GRC-RCN0[VZ]
- [Iccrg] Heresy recapped S. Keshav
- [Iccrg] Heresy recapped Lars Eggert
- [Iccrg] Heresy recapped Matt Mathis
- [Iccrg] Heresy recapped Lachlan Andrew
- [Iccrg] Heresy recapped S. Keshav
- [Iccrg] Heresy following "TCP: Train-wreck" Lachlan Andrew
- [Iccrg] Heresy following "TCP: Train-wreck" Dirceu Cavendish
- [Iccrg] Heresy following "TCP: Train-wreck" Dirceu Cavendish
- [Iccrg] Heresy following "TCP: Train-wreck" Bob Briscoe
- [Iccrg] Heresy following "TCP: Train-wreck" Dirceu Cavendish
- [Iccrg] Heresy following "TCP: Train-wreck" Matt Mathis
- [Iccrg] Heresy following "TCP: Train-wreck" Bob Briscoe
- [Iccrg] Heresy following "TCP: Train-wreck" Bob Briscoe
- [Iccrg] Heresy following "TCP: Train-wreck" Dirceu Cavendish
- [Iccrg] Heresy following "TCP: Train-wreck" Lachlan Andrew
- [Iccrg] Heresy following "TCP: Train-wreck" Bob Briscoe
- [Iccrg] Re: Heresy in Minneapolis Bob Briscoe
- [Iccrg] Re: Heresy in Minneapolis Lisong Xu