[Iccrg] Re: I-D
bob.briscoe at bt.com
Sun May 25 21:15:38 BST 2008
[sending again, now I've subscribed the different @ I was sending
from to the cc'd list. I've also added another comment so pls read
this one, not the last.]
Tx for comments. SOrry for lack of previous response (I'm having big
SMTP relay problems - might have been the cause)
At 03:13 21/05/2008, Brian E Carpenter wrote:
>I didn't see a reply to my initial questions, but below
>are my comments on the draft as a whole (which I found quite
>thought-provoking, so thankyou!).
>On 2008-04-29 11:11, Brian E Carpenter wrote:
> > Hi,
> > I'm reading your draft with interest but have two questions
> > before I start commenting...
> > 1. Are there references for the assertion in section 3.3
> > that "most congestion seen on today's Internet is due to
> > an excess of bits rather than packets"? I have to say
> > I found this surprising and I'm curious about the evidence.
In my talk to the ICCRG about [Bri08], I said I couldn't find any
actual paper studies. But Larry Dunn said people who designed router
hardware worked on the design goal of handling a run of the smallest
possible packets. Nonetheless the law of economic compromises drives
them to not quite achieve this, because they can make the performance
stats look better by designing for a more typical packet mix, and
buffering up runs of small packets to a certain degree.
So this suggests that routers will only get into packet congestion
problems when there are long runs of minimum size packets (acks or
DoS), but normally they will be operating under bit congestion on the
output interfaces, rather than packet congestion on the inputs.
Does this ring true now it's said with a little more longhand
background? If you have any contrary evidence, it would be great (tho
problematic in terms of further cc issues).
> > 2. There are citations later in section 3.3 of [Bri08] but
> > there is no such reference listed. Is that meant to be [Bri07],
> > [Bri06], or something else?
Answer is 'Something else'
- whoops - it was missing from refs:
Byte and Packet Congestion Notification
> 3.1.1 Performance and robustness
> - What is the minimum support that is needed from routers in order
> to achieve significantly better performance than with end-to-end
>BC: Can you add the obvious: without damaging the end-to-end principle.
I'd certainly agree to that. Co-authors?
> 3.2 Challenge 2: Corruption Loss
> Open questions concerning corruption loss include:
> - How should corruption loss be detected?
> - How should a source react when it is known that corruption has
>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.
> 3.3 Challenge 3: Small Packets
> o) Confusable Causes of Drop
> There is a considerable body of research on how to distinguish
> whether packet drops are due to transmission corruption or to
> congestion. But the full list of confusable causes of drop is longer
> and includes transmission loss, congestion loss (bit congestion and
> packet congestion), and policing loss
>BC: Wouldn't the impact of some kind of QOS support belong here, more
>generally than "policing"? Certainly if diffserv queue management is
>in place, you'll see differential drop behaviors.
Altho that's a valid point, I think it's orthogonal to the issue
here, which was: "What should I (the transport) do if I see a drop?
And is there anything we as protcol designers can do to distinguish
between different sorts of drop so transports don't have to act based
on the most pessimistic assumption?"
In the Diffserv case, the differential drop is predicated on an
assumption that endpoints will respond the same to one drop, whatever
the class it's from. So dropping more not only differentiates service
delivery, but will probably leverage standard congestion response
(e.g. TCP) behaviours to considerably inflate the differentiation.
But see discussion on Gibbens paper below.
> 3.6 Challenge 6: Precedence for Elastic Traffic
> The preferential treatment of higher precedence traffic with
> appropriate congestion control mechanisms is still an open issue that
> may, depending on the proposed solution, impact both the host and the
> network precedence awareness, and thereby congestion control.
> - Discuss existing work on low-priority flows - why isn't this stuff
> used? That's an open issue, interesting things could be done with it!
[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"
>BC: Well, good question. Maybe the authors of RFC 3662 have ideas.
>Internet2 experimented with a scavenger service, too, although
>that seems to have faded some years ago.
> - Discuss DiffServ [RFC2474] [RFC2475] related aspects with
> congestion control.
>BC: In diffserv we sort of assumed this was orthogonal, i.e. would
>be an end to end issue. But (as noted above) there will be
>different dropping disciplines for different traffic classes.
Yes, e.g preferential drop of EF/AF etc, Pre Congestion Notification (PCN) etc.
>There is scope for new thinking there.
Certainly. There's an interesting point of view that says (when ECN
is supported rather than drop) that higher priority traffic should
see higher ECN marking not lower. Reflecting the sum of the lengths
of the queue for the traffic's own class and all the other queue(s)
backed up behind it.
Richard J. Gibbens and Frank P. Kelly, "On Packet Marking at Priority
Queues," IEEE Transactions on Automatic Control 47 (6) pp.
1016--1020 (June, 2002).
This comes from a world where fairness is determined by limiting the
amount of congestion marking you can cause, because it reflects the
actual congestion you are causing to all classes, not just your own.
Of course, it is also predicated on a world where you are allowed
weighted response to congestion (so if you choose a high weight, you
respond less to the same level of congestion as others with a lower
weight congestion control).
>I should point out that diffserv turned the RFC791 notion of
>"precedence" into a multidimensional notion; traffic classes
>can have several properties which are almost orthogonal
>to each other. Precedence is a very simple-minded way to share
Yup - we should fix this terminology.
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