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

[S. Keshav]

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.
	So, a discussion of fairness, and its relationship to congestion is  
well worth having.

> It will help answer the question in this thread about striping  
> aross multiple paths, and generally completely re-boots most  
> people's understanding of fairness, showing just how impractical  
> and unrealistic the current way we think about fairness is.
>
>
>
Let me also handle Michael's comment from a while back:
>  Michael Welzl wrote:
>> > 1. What we know. Known 'good' approaches - i.e. whats common to the
>> > proposals out there.
>>
>> but what exactly shall we expect to learn from / accomplish with  
>> this?
>> I mean, we can write an overview, looking at commonalities ... to
>> be concrete, I think this can be something like "delay has been used
>> as a congestion measure in ... Vegas, FAST, ... it has the following
>> advantages, the following disadvantages..."  ... and so on and so  
>> forth.
>>
>> That might be nice, but I'm having a hard time imagining that this
>> will take us anywhere. 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?
>>
>> And what would it accomplish that the others don't?

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.
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.
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).
10. Reasonable fairness among instantiations of itself and some  
measure of fairness towards conventional TCP.

--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).
3. The tool is to be based on transport with implicit congestion  
signaling (see requirement 7).
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).

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?

thanks
keshav