[Iccrg] Re: I-D ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.txt

[Bob Briscoe]

Brian,

[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)

inline...

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
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>


>  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
>      mechanisms?
>
>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
>      occurred?
>
>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.
>
>    TODO:
>    - 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"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>
(3pp)


>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.
>http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt
>
>    - 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.

See
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
>resources.

Yup - we should fix this terminology.

Cheers


Bob


>Regards
>      Brian

____________________________________________________________________________
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