[Iccrg] Meeting agenda (really! :-) )

[Bob Briscoe]

Keshav,

At 20:41 11/10/2006, S. Keshav wrote:
>Bob,
>This sounds like a good discussion to have. The need for fairness has
>been grossly exaggerated, in my opinion, and is hard to justify. If
>scheme A is fair to all users, and scheme B is unfair, but every user
>with scheme B gets more than the same user with scheme A, would you
>prefer B to A? I would.

Of course. But such a situation would be extremely unusual. All the 
practical scenarios involve conflicts of interests, with some users getting 
more and some less.

I have to disagree that the need for fairness is hard to justify. In 
particular, in a non-co-operative environment (like the Internet, which is 
after all the object of debate), if the view of fairness that prevails 
cannot be /enforced/, then some users can take orders of magnitude more 
than their 'fair' share. Then, what is the point of even having a 
congestion control protocol?

But to enforce a view of fairness, the enforcers (deliberately 
non-specific) have to know what fair means in the first place.

>         So, a discussion of fairness, and its relationship to congestion is
>well worth having.
>
>Let me also handle Michael's comment from a while back:
>>  Michael Welzl wrote:
>>>Also, such overviews exist - how much
>>>should the overview differ from, say, this one:
>>>http://transport.internet2.edu/transport-design-space.pdf
>>>or the others in our Wiki?
>
>Good point. Since this work has already been done, it would be useful
>for ICCRG to bless them, assuming we agree with the conclusions. For
>the benefit of readers on this list, here is the set of requirements
>and conclusions from the paper Michael pointed to:
>
>--Paraphrased requirements (eliding application level requirements) --
>3. .. deployable without the need to negotiate with organizational
>information technology departments
>that might have standardized on.

I don't think we need be so specific. 'Incremental deployment and 
incentives properly considered' would be sufficient. Deployment into some 
environments requires the IT dept to veto (eg into machines in my company - 
but strangely not my laptop ;), in others it doesn't.

>4. Ability to transfer at speed that are close to 1Gb/s in near term
>and 10 Gb/s in medium term
>with, preferably, no fundamental limitations on performance in longer
>term.
>5. Ability to be used both for straightforward bulk file transfer and
>advanced interactive multimedia applications that can require
>unreliable (and partially reliable) datagram service.
>6. Tolerance for minor non-congestive packet loss.
>7. Lack of dependence on network upgrades or configuration changes,
>especially those that involve
>all routers along the path.

Again, good guidance, but too specific. I'd rather see this statement as a 
suggested example of the statement 'Incremental deployment and incentives 
properly considered', rather than a law. Our own (so far unpublished) work 
we would actually meet your requirement, but I don't think we should rule 
out other approaches that don't meet it if they can justify their position.

For instance, in my review of QuickStart (expired I-D on my pubs page) I 
proposed a simple mathematical deployment model to show that 'incrementally 
deployable' was too bold a claim for QuickStart, but that doesn't mean it 
isn't a useful experimental step in some environments.

>8. Usability over a wide range of scenarios without complex tuning.
>9. Ability to be tuned for the most unusual of circumstances (such as
>lossy radio links).

Contradicts 8, but I know what you mean - just needs wordsmithing.

>10. Reasonable fairness among instantiations of itself and some
>measure of fairness towards conventional TCP.

Well, this one I fundamentally disagree with, but a deconstruction requires 
a paper, not an e-mail... so watch this space.

>--Paraphrased conclusions--
>... we draw the following conclusions for the transport tool (the
>requirements
>mentioned below are listed in section 1):
>
>1. The congestion control scheme needs to be TCP friendly without
>emulating TCP (see requirement 10).

Ditto

>3. The tool is to be based on transport with implicit congestion
>signaling (see requirement 7).

This may be proved impossible at high link speeds (see below) - what then? 
I think this is part of the debate - too early to gainsay as a requirement.

>4. The implicit congestion signaling scheme (to be used according to
>conclusion 3) is to be primarily
>delay-based with fail-over to a standard loss-based algorithm when
>persistent congestion is
>detected (see requirements 6, 4, and 10).

Again, part of the debate, not a requirement, IMHO.

As link speeds increase, congestion delay decreases (especially given the 
conclusions people are coming to on small buffers). Then congestion delay 
becomes an extremely imprecise measure of congestion (see thread just 
started on per packet congestion signalling channel bandwidth).

>So, does everyone agree that future congestion control protocols must
>be implicit, TCP friendly, and primarily
>delay-based with fail-over to a standard loss-based algorithm?

Actually I disagree with all of these conclusions.

Cheers


Bob


____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196