[Iccrg] Re: I-D
rbriscoe at jungle.bt.co.uk
Fri May 30 18:45:07 BST 2008
At 04:06 27/05/2008, Brian E Carpenter wrote:
> >> BC: Is there also a question of how to distinguish corruption affecting
> >> a single stream from corruption affecting multiple streams?
> > Do you mean multiple streams with a common endpoint, or independent
> > endpoints?
> > You obviosuly have something in mind. I can't see why you'd need to do
> > this, unless there was someting you could do different in each case.
>Since we're presumbly discussing endpoint behavior, I was thinking of the
>case where multiple streams from or to the same endpoint are all experiencing
>corruption simultaneously. That fact obviously has diagnostic value
>since it says that the corruption is occurring near the endpoint.
>I'm not sure the transport layer can do much with it, but it might
>be a useful indication for a lower layer (e.g. a hint to drop the bit
>rate on a wireless interface). You might feel this is out of scope...
Not quite OOS, but pretty close to OOS.
> > [Added while re-sending posting:]
> > The position paper I have in the IETF p2p infrastructure workshop on Wed
> > outlines an interesting equivalence between using Diffserv to do a
> > background class and using weighted endpoint congestion control to do
> > weighted sharing. It briefly explores the practical deployment issues of
> > each.
> > "Solving this traffic management problem... and the next, and the next"
> > <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>
> > (3pp)
>Yes, that's an interesting point. But the risk of people "cheating"
>is real, so I don't see some form of inspection-based policing
For such policing we've defined what we believe is necessary and
sufficient in a self-contained datagram to ensure transports will
respond sufficiently to congestion without per-flow processing, with:
- minimal harm to evolvability (e2e principle)
- minimal constraint on user freedom
Our proposal needs the last available bit in IPv4 to achieve
That's been my and my team's research for the last 11 years (the
above link tries to summarise the insights without pushing our
For the specifics, see our project page:
Bob Briscoe, <bob.briscoe at bt.com> Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
More information about the Iccrg