Subject: Re: [PCN] Architecture draft- bi-directional flows

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 3 Feb 2008 22:30:24 -0500

For admission control, the application needs to know that both
directions are able to support the new flow before completing the
bi-directional flow setup. 
For flow termination if there are multiple congestion points,
termination of bi-directional flows may cause reduction of congestion on
other paths. Any mechanisms that attempts to terminal traffic in one
step will generally cause over termination (more bi-directional flows
are terminated then needed). 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: January 25, 2008 9:37 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: PCN IETF
Subject: Re: [PCN] Architecture draft- bi-directional flows

Hi,

On 2007-12-17, at 16:58, ext Jozef Babiarz wrote:
> I believe that the PCN Architecture draft needs to discuss and explain
> how admission control and flow termination works at high level for
> telephony and video conferencing applications and that both, telephony
> and video conferencing applications have bi-directional flows. For
> admission control a new flow can not be admitted unless the traffic
> level on both unidirectional paths is below the PCN-lower-rate. As  
> well
> for flow termination, a bi-directional flow is terminated if one of  
> the
> unidirectional paths is in excess of PCN-upper-rate.

can you elaborate a bit why something more is needed than simply  
setting up both directions independently, and failing if that didn't  
work? Or, for termination, when the app realizes that one direction  
got torn down, it tears down the other direction?

Lars
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 3 Feb 2008 23:22:32 -0500

Phil,
I'm OK with description of bi-directional flows in Section 6.

My comment to Lars and PCN WG is that bi-directional flows have
additional requirements that both admission control and flow termination
mechanism need to accommodate.  I believe that the different PCN marking
drafts need to explain how their proposed mechanism works with
bi-directional flows.   

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: January 29, 2008 9:21 AM
To: [email-masked]; Babiarz, Jozef (CAR:0S03)
Cc: [email-masked]
Subject: RE: [PCN] Architecture draft- bi-directional flows

Note, bi-directional flows are discussed in the arch draft already.
Section 6,
http://tools.ietf.org/html/draft-ietf-pcn-architecture-02#page-24 says 

   o  Bi-Directional Sessions: Many applications have bi-directional
      sessions - hence there are two flows that should be admitted (or
      terminated) as a pair - for instance a bi-directional voice call
      only makes sense if flows in both directions are admitted.
      However, PCN's mechanisms concern admission and termination of a
      single flow, and coordination of the decision for both flows is a
      matter for the signalling protocol and out of scope of PCN.  One
      possible example would use SIP pre-conditions; there are others.

Hopefully this is enough?

> Sent: 25 January 2008 14:37
> To: ext Jozef Babiarz
> Cc: PCN IETF
> https://www1.ietf.org/mailman/listinfo/pcn

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Feb 2008 10:30:07 +0200

> bi-directional flow setup.

The way in which an application learns whether the path can support a  
flow is by trying to set it up. Either admission succeeds or it  
doesn't. For a bi-directional flow, it tries to set up both  
directions, and uses them if both setups succeed.

I don't understand how an application would get information about  
whether an intended flow setup can succeed *before* attempting to set  
it up.

> are terminated then needed).

I think you argue here that PCN should have a mechanism to identify  
flows that are part of a bidirectional flow pair, and use that  
information in its termination decision. (With the assumption that  
tearing down one half of a flow pair will free up capacity in the  
other direction, too.)

This seems to be an optimization of the flow termination scheme that  
hasn't seen much discussion in the WG so far, and the implication on  
the architecture are pretty complex. I also question the need to  
engineer such complex termination mechanisms in the first place -  
termination is a last resort to shed load, and optimizing its behavior  
doesn't seem critical. If you need to terminate, things have gone  
pretty badly within the PCN domain already, so its questionable if the  
PCN state is even accurate enough to allow any sort of intelligent  
behavior.

Lars