Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt

From: Michael Menth <[email-masked]>
Date: Mon, 18 Dec 2006 14:31:38 +0100

Hi Joe et al.

I've browsed again through the draft
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-sip-cap-00.txt
Many aspects in this draft like probing etc. are of general nature 
regarding PCN and are not SIP-specific. This hides the SIP-specific 
problems. Probing is certainly a good thing to do to avoid flash crowds 
and ECMP problems, but the IntServ over DiffServ model would equally 
benefit from probing.

Regarding the interaction between SIP and the PCN architecture I see two 
possible options (maybe mixed approaches are also possible):
1) SIP uses PCN admission and preemption provided by the ingress nodes 
of the PCN domain.
2) PCN border nodes only provide probing and measurement and send the 
raw measurement data to the SIP proxy which takes the admission and 
preemption decisions.

I think 2) is favored in the draft. However, I still miss the full 
picture: which entity does what and communicates what to which other entity?

Some comments to both approaches:

ad 1) SIP uses PCN
* The PCN ingress selects the flows being preempted which is unaware of 
session structures. (-)
* SIP contacts the PCN ingress like any other flow would do and waits 
for an answer. Therefore, this approach can coexist with RSVP and other 
signaling schemes as PCN border routers control the resources of the 
network. (+)
* No single point of failure (+)

ad 2) SIP implements PCN
* SIP triggers PCN border routers and receives information from them. 
Based on this information, admission and preemption decisions are made. 
Details are not clear to me yet. (o)
* SIP selects the flows being preempted: correlated streams may be 
preempted together, e.g., voice and video of application X instead of 
voice of X and video of Y. (+)
* SIP control makes coexistence with other resources control paradigms 
difficult (-)
* SIP control is single point of failure like a bandwidth broker (-)

Best regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 18 Dec 2006 17:34:10 +0100

Hi Bob,

although border cheating isn't part of the currently 
discussed pcn charter, I prefer to communicate my 
comments using this mail exploder. I'm happy to 
continue this discussion privately, should others 
feel this to be preferable.

You propose a mechanism allowing to identify ingress 
gateways to a PCN region ignoring feedback on ECN 
marked packets which was given them. Your 
argumentation is that intermediate transit networks 
providing bulk CL transport must have a way to 
ensure "fair use of resources" while maintaining the 
agreed CL service level.

You are right in your conclusion on the required 
ability of a transit network to monitor the behaviour 
of traffic sinks after pre congestion notifcation 
occurred within this transit network, I think. While 
I think, that the mechanism you propose is smart and 
may work, I'm not sure, whether the accounting 
mechanism surrounding it should or could be 
standardised by IETF.

I'd prefer not to enter a detailed discussion on 
the usefulness of your proposed solution. Instead, 
I'd like to list a couple of thoughts coming to 
my mind:

- The egress gateway feeds back the PCN information 
  to the ingress gateway. It could at least monitor 
  RSVP signaling after PCN feedback has been given 
  by it. 
  If it expects PATH messages after PCN feedback 
  to be followed by PathErr sent from the ingress 
  and receives refreshes instead, a cheat is easily 
  identified. But that is obviously of no help, if 
  the traffic contract of an admitted reservation 
  isn't kept.

- Ingress/Egress gateway per flow policing probably 
  is the only way to ensure correct behaviour of 
  sources (and avoid cheats on consumed bandwidths).

- The transit networks sell a bulk service. They 
  aren't aware of any per flow events and don't 
  care as long as the CL/PCN service operates 
  properly.

- The transit provider charges for CL traffic 
  volumes and provides an SLA on two things:
  * CL performance (close to loss free)
  * Probability to cause ECN marks to be set on 
    an internal bottleneck (let's call it a "network 
    busy indication", should have a low probability).

- Per transit domain (ingress-egress?) aggregate 
  PCN and CL reports may have to be produced anyway.
  They prove who has contributed to a network busy 
  situation in a chain of networks for ECN marks. 
  For CL traffic, they prove loss free operation.

- The downstream egress (gateway) can't determine 
  where and by which network an ECN mark has been 
  set. I'd expect the egress border routers/gateways 
  noticing ECN marked traffic not to have an interest 
  in cheating as they could hit own customers.

- The ingress can only cheat on a secure basis, if 
  it can be sure that it isn't the own network 
  producing the ECN marks. This assumes some form of
  ECN feedback from its border router (assuming the 
  ingress gateway to be part of a domain, not a 
  single service production point).

- The hard part seems to be to identify and trace 
  back a cheater in the case of a chain of transit 
  networks and pre congestions marks set by a 
  downstream network are ignored by an upstream 
  ingress gateway. But that assumes that the ingress 
  operator knows that congestion isn't occuring close 
  to him and probaly also requires the egress gateway 
  to cooperate.

To sum up, I'd prefer a deeper analysis of the scenarios 
and architectures around cheating before discussing 
solutions.

I've read the March version of your draft - after a brief 
glance on the June version. I still think they mostly 
represent my thoughts on your input. 

Regards,

Rüdiger

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Mon, 18 Dec 2006 12:11:09 -0500

Michael:
Thank you very much for your comments.
We are currently working on the next version of this draft based
on the feedback we received during the BOF in San Diego.

Please see below for initial response to your comments.
-- Kwok --

At 08:31 AM 12/18/2006, Michael Menth wrote:
>problems. Probing is certainly a good thing to do to avoid flash 
>crowds and ECMP problems, but the IntServ over DiffServ model would 
>equally benefit from probing.

Some of the work here may be applicable to more than just this 
Deployment Model, but possibly
with different degree of importance.  Hence these topics may need to 
be explored in general.
My personal view point is there are more commonalities then 
differences between the current
two deployment models, hence my recommendations to have both of them 
in the first phase charter
of PCN.

>Regarding the interaction between SIP and the PCN architecture I see 
>two possible options (maybe mixed approaches are also possible):
>1) SIP uses PCN admission and preemption provided by the ingress 
>nodes of the PCN domain.
>2) PCN border nodes only provide probing and measurement and send 
>the raw measurement data to the SIP proxy which takes the admission 
>and preemption decisions.
>

I think this should be better clarify in the next version of the draft.
We are planning to have a more top down approach with the next version
and possible defer some of the details.
Hopefully the next version can better clarify the full picture.

>* The PCN ingress selects the flows being preempted which is unaware 
>of session structures. (-)
>* SIP contacts the PCN ingress like any other flow would do and 
>waits for an answer. Therefore, this approach can coexist with RSVP 
>and other signaling schemes as PCN border routers control the 
>resources of the network. (+)

For a real solution, no matter what signaling protocol is used, the 
source of the packets should stop
sending the packets that contribute to the perceived 
congestion.  Hence even in the RSVP as signaling
protocol in the middle of the network deployment model, the sender of 
the traffic needs to be notified.
It is just in the SIP-CAP deployment model, we are more specific on this point.
And in this approach you indicated, there are room for 
inter-operability.  Hence we want to have the
PCN  mechanism we are standardizing in the first phase charter to be 
applicable to both deployment
models.  And I believe this should be a goal.

>ad 2) SIP implements PCN
>* SIP triggers PCN border routers and receives information from 
>them. Based on this information, admission and preemption decisions 
>are made. Details are not clear to me yet. (o)
>preempted together, e.g., voice and video of application X instead 
>of voice of X and video of Y. (+)
>* SIP control makes coexistence with other resources control 
>paradigms difficult (-)

Thanks for your comments, I think with clearer description in the 
next version of the draft,
you may see more (+)s.  We will keep your comments in mind to make 
sure we address them.
And will provide you with more detailed response using contents of 
the new version of the draft.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Dec 2006 18:12:17 +0000

Rüdiger,

Just about to take a day off (xmas shopping). Will respond when I return.

Regarding whether this should be on or off list, I think the general 
sentiment at the PCN BoF was that inter-domain should be held strongly in 
mind while focusing first on intra-domain (reflected in the new wording in 
the proposed charter). So, given the border-cheating draft is currently one 
of the only ways to both keep good scalability and go inter-domain, it is 
certainly worth discussing whether it is a meaningful approach for going 
inter-domain, and whether it involves anything standardisable anyway 
(you'll notice my intent was for this draft to be informational, but there 
may be some standardisable elements).

If it's not an acceptable approach, then we need to be looking for other 
solutions. Because if we can't see how to take the last steps, interest in 
taking the first steps towards PCN will be lessened.

I'll leave others to argue if they don't think this discussion belongs on 
the list.

More in a couple of days.

Bob

>represent my thoughts on your input.

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 21 Dec 2006 10:14:04 -0500

Michael, please see comments below:

Regards, Joe
Email: [email-masked]

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Monday, December 18, 2006 8:32 AM
To: [email-masked]
Subject: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt

>and ECMP problems, but the IntServ over DiffServ model would equally 
[Joe] Yes, I also believe that the probing concept adds value in the
IntServ over DiffServ model. Note, I'm not trying to hide any
SIP-specific issue, just wanted to provide a high level overview using
SIP as an example.

>Regarding the interaction between SIP and the PCN architecture I see
two 
>raw measurement data to the SIP proxy which takes the admission and 
[Joe] Actually what I proposed in the draft is different, however what
you proposing could be a method for currently defined IntServ over
DiffServ model to interact with SIP application control. I mentioned in
the draft-babiarz-pcn-sip-cap-00 that the PCN marking behavior for
preemption is a bit different than what is currently in
draft-briscode-tswwg-cl-phb-02. What I'm proposing is that interior
routers explicitly signal via setting of bits in the IP header the
action that end nodes (hosts or edge routers) should take. For
preemption the concept is similar to what is defined for ECN in RFC3168.
In other words, edge nodes just need to react to the marking. i.e., stop
admitting of new flow or preempt already admitted PCN marked follow(s)
should the need arise. With this approach, only the interior routers
perform traffic level measurements and explicit mark to indicate the
action that the edge nodes need to take. I'm planning to do a write-up
with simulation and see what everyone thinks of this approach for PCN
marking.

---

From: Michael Menth <[email-masked]>
Date: Thu, 21 Dec 2006 16:25:49 +0100

Hi Joe,

> with simulation and see what everyone thinks of this approach for PCN
I don't see the difference to the functionality of
http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-04.txt
So pointing out the differences in your draft would be helpful for me 
and probably also for others to recognized what's different and 
facilitates a discussion.

Best wishes,

    Michael

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 21 Dec 2006 10:40:48 -0500

Michael wrote: 
>http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture
->04.txt
>facilitates a discussion.
[Joe] OK, will do.

Regards, Joe

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: Thursday, December 21, 2006 10:26 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: Re: [PCN] Comments on draft-babiarz-pcn-sip-cap-00.txt

Hi Joe,

>> problems. Probing is certainly a good thing to do to avoid flash
crowds
>> 1) SIP uses PCN admission and preemption provided by the ingress
nodes 

http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-cl-architecture-
04.txt

Best wishes,

    Michael

>> * The PCN ingress selects the flows being preempted which is unaware
of

>> * SIP control makes coexistence with other resources control
paradigms