Subject: [PWE3] Work in common with draft-rosen-pwe3-congestion-03.txt

From: Bob Briscoe <[email-masked]>
Date: Tue, 11 Jul 2006 20:58:19 +0100

Eric, Luca, Bruce, Stewart,

[I'm not involved in the PWE3 w-g, so I've just joined the list temporarily 
to post this. Pls include my e-mail explicitly in any follow-up.]

David Black just pointed me at your draft
         PWE3 Congestion Control Framework
         draft-rosen-pwe3-congestion-03.txt

On reading, it looks like you're up against all the same issues as we are. 
Even tho we are generally using ECN, and you have chosen to require to be 
able to work without it, there is a fair bit of overlap that points to 
potential for mutual help. (BTW, Bruce & I are proposing a new approach to 
add ECN to MPLS in the MPLS w-g, which would help.)
I notice in Sec 2. you talk of detecting congestion over set sampling 
periods at PW egress. It would surely be better (and very efficient) to use 
an exponentially weighted moving average. This can be done with two adds 
and a shift per packet. An algorithm for this is in Appendix 11.3 of "An 
edge-to-edge Deployment Model for Pre-Congestion Notification: Admission 
Control over a DiffServ Region".
         <<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-03.txt>draft-briscoe-tsvwg-cl-architecture-03.txt> 

Reference [RSVP-PCN] (by Francois le Faucheur) in the above draft proposes 
an extension to RSVP to transport the congestion feedback regularly, but 
infrequently. This made sense for us, because we were already using RSVP 
for reservation signalling, but you may want to consider it for 
drop-related congestion, not just ECN.

Perhaps I misunderstood, but one thing that concerns me about your draft is 
that edge-edge congestion control should surely only be done for flows that 
aren't already responding to congestion on an end-to-end basis. Otherwise, 
for those flows, you will be responding twice. Worse, if you slow the input 
rate to the PW, you will buffer up at the ingress, leading to drop when 
this buffer overflows, causing a third congestion response (end-to-end).

But if you want to selectively do edge-edge congestion control, you can't 
simply only manage the input rate of packets with UDP as the transport 
header, because some UDP apps do congestion control at the app layer, while 
others don't. (For that matter, a malicious app may identify itself as TCP 
but not do TCP congestion control). There's no clear way to identify which 
flows are doing congestion control and which aren't.
Finally, the reason David originally pointed me at your draft was to 
encourage me to bring to your attention other work of ours - on enabling 
networks to police congestion control. Although you mention policing (and 
policing in multi-domain scenarios) a number of times I don't think you are 
particularly concerned about traffic maliciously not responding to 
congestion. You seem more concerned to provide a mechanism for a PW to do 
congestion control, on the assumption it has a will to do it, it just 
doesn't have a way to do it.

But if you are concerned about policing, we have a solution to that too - a 
strategic architectural change to IP itself. We have fully spec'd the 
solution in a draft being progressed in tsvwg (but not a w-g draft yet):
         Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
         <<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-02.txt>draft-briscoe-tsvwg-re-ecn-tcp-02.txt> 

the idea is to be able to police congestion control of the whole range of 
possible responses to congestion - from hi-speed cc, thru TCP-friendly to 
admission control for CBR-like flows. Particularly relevant to your case, 
we have a draft that works in an edge-edge arrangement with infrequent 
feedback (it focuses on the CBR-like case you mention, but more elastic 
congestion control could be used similarly):
         Emulating Border Flow Policing using Re-ECN on Bulk Data
         <<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt>draft-briscoe-tsvwg-re-ecn-border-cheat-01.txt> 

Hope this all helps

Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3