[Iccrg] Soliciting input for cc. bibliography

[Wesley Eddy]

On Tue, Jun 13, 2006 at 11:36:01PM +0200, Michael Welzl wrote:
> > For the CC-related RFCs, the TCP Roadmap already covers this ground (and
> > hopefully does so pretty well).  To me it does not seem valuable for the
> > ICCRG to spend a lot of time rehashing this, or asking participants to
> > review another, different, book report of this same material.  The
> > relevent roadmap portions are:
> > http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000064.html
> 
> As much as I like the roadmap, it is by no means a complete
> overview of congestion control related RFCs - it's strictly
> about TCP, with no mention of, e.g., multicast congestion
> control, DCCP, Active Queue Management (RFC2309), link layer
> interactions with congestion control...
>
> The way I looked at this document is that it would give
> an overview of congestion control work in the IETF *except*
> for the things that are in the roadmap already (and that
> it would of course point to the roadmap as the main reference
> on anything TCP related) - and this is more than you might
> expect - see my previous post:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-March/000066.html
> for an incomplete list.
>

Ah, in that case, I do think this would be valuable to work on.  The list
of RFCs in that link contains a lot of overlap with the roadmap, and I
guess that was what confused me.

> > On the other hand, a document that itemizes and describes the more
> > radical congestion control algorithms would be valuable, and I think the
> > group should concentrate on this deliverable.  To my knowledge, the only
> > such algorithms that are currently described in RFCs are HighSpeed
> > and Limited Slow-Start, so the TCP Roadmap does not even begin to cover
> > this area.
> 
> Do you still think that this should all be compiled
> in a single document in the light of what I said above?
>

I don't think it matters.  Smaller documents might generate more reviews
from the group than a single giant document, but I don't think it's
significant one way or the other,

-- 
Wesley M. Eddy
Verizon Federal Network Systems