Subject: [PCN] Piggybacking -- a new edge behaviour

From: Tom Taylor <[email-masked]>
Date: Tue, 06 Oct 2009 19:34:56 -0400

Bob and Phil in particular have expressed interest in documenting a mode of 
operation whereby PCN information is "piggybacked" on top of resource 
signalling. One of the desirable properties of this is fate sharing: if the 
message from the egress node goes missing, the flow is not admitted.

We co-authors of the signalling requirements document had a discussion today to 
clarify the content of our draft. It was clear to me as a result of this 
discussion that piggybacking has to be treated as a separate edge behaviour. 
This behaviour differs from CL and SM because:

(1) it assumes that resource signalling is being used;

(2) it assumes that the egress node makes the admission decision for each flow 
based on its current CLI estimate, whereas CL and SM both assume the per-flow 
decision is made elsewhere;

I propose to write a separate draft describing this edge behaviour.

If the piggybacking edge behaviour is restricted to admission control only, it 
has no signalling requirements above those already defined for resource 
signalling. There is no point in transporting the CLI estimate back to the 
ingress node given that the egress node is the place where it is used.

The interesting question is whether we would want the piggybacking edge 
behaviour to support flow termination. If it does, a signalling requirement 
exists, to transport the current estimate of supportable rate back to the 
ingress node. I think it is up for discussion whether this information would be 
piggybacked in the per-flow resource signalling or sent by a separate message. 
If the latter is the case, I would argue that the transport solution(s) 
specified for PCN should be used, whatever it is/they are.

Note that the charter says PCN can define the requirements for a signalling 
protocol, but cannot specify the protocol itself. That means it's someone else's 
job to say what PCN's signalling transport is. (AD bait here -- I think the 
charter was written making some unstated assumptions.) We can't assume resource 
signalling will be the chosen vehicle, taking note that if it is chosen, 
Ruediger's network will not support it.

Tom

---

From: Michael Menth <[email-masked]>
Date: Wed, 07 Oct 2009 01:43:49 +0200

Hi Tom,

I thought that Bob's and Phil's proposal with piggybacking was the 
following. If many RESV messages are sent from the egress to the ingress 
to do per-flow resource signalling, the per ingress-egress-aggregate 
information from the egress to the ingress can be piggybacked on top of 
these per-flow RESV messages. That's what I understood when talking to 
them last time.

Bob, Phil, can you clarify, please?

Kind regards,

    Michael

Tom Taylor schrieb:
> Bob and Phil in particular have expressed interest in documenting a 
> mode of operation whereby PCN information is "piggybacked" on top of 
> resource signalling. One of the desirable properties of this is fate 
> sharing: if the message from the egress node goes missing, the flow is 
> not admitted.
>
> We co-authors of the signalling requirements document had a discussion 
> today to clarify the content of our draft. It was clear to me as a 
> result of this discussion that piggybacking has to be treated as a 
> separate edge behaviour. This behaviour differs from CL and SM because:
>
> (2) it assumes that the egress node makes the admission decision for 
> each flow based on its current CLI estimate, whereas CL and SM both 
> assume the per-flow decision is made elsewhere;
>
> If the piggybacking edge behaviour is restricted to admission control 
> only, it has no signalling requirements above those already defined 
> for resource signalling. There is no point in transporting the CLI 
> estimate back to the ingress node given that the egress node is the 
> place where it is used.
>
> The interesting question is whether we would want the piggybacking 
> edge behaviour to support flow termination. If it does, a signalling 
> requirement exists, to transport the current estimate of supportable 
> rate back to the ingress node. I think it is up for discussion whether 
> this information would be piggybacked in the per-flow resource 
> signalling or sent by a separate message. If the latter is the case, I 
> would argue that the transport solution(s) specified for PCN should be 
> used, whatever it is/they are.
>
> Note that the charter says PCN can define the requirements for a 
> signalling protocol, but cannot specify the protocol itself. That 
> means it's someone else's job to say what PCN's signalling transport 
> is. (AD bait here -- I think the charter was written making some 
> unstated assumptions.) We can't assume resource signalling will be the 
> chosen vehicle, taking note that if it is chosen, Ruediger's network 
> will not support it.
>
> Tom
>
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 7 Oct 2009 10:05:39 +0300

Hi,

On 2009-10-7, at 2:34, Tom Taylor wrote:
> signalling
> charter was written making some unstated assumptions.)

OK, I'll bite :-)

It's not so much unstated assumption as a strong desire to not charter  
open-ended WGs, so we tried very hard to chop off the smallest  
possible set of initial work items when the WG was chartered. So  
important stuff is missing until after a recharter (e.g., inter-domain  
behavior, etc.) For signaling specifically, at charter time it sounded  
like there were multiple different use cases (ITU-T etc.) some of  
which had pre-existing signaling protocols and which wanted to roll in  
PCN support into whatever their broader architecture was. Hence, we  
decided to not mandate one signaling protocol.

If that's now different, we can definitely talk about what to do at  
rechartering time (when a few more of your initial work items are  
nearing completion...)

Lars

---

From: <[email-masked]>
Date: Wed, 7 Oct 2009 13:56:10 +0200

Tom,

I agree to your proposal.

Regards, Ruediger 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Wednesday, October 07, 2009 1:35 AM
To: pcn
Subject: [PCN] Piggybacking -- a new edge behaviour

Tom

---

From: <[email-masked]>
Date: Mon, 12 Oct 2009 15:53:28 +0100

Hi

I think what Michael says basically agrees with what tom says (?)

For admission control there seem to be 2 cases, basically as tom says:

- where pcn signalling fate shares with existing resource signalling, eg
by "piggybacking" in the RESV msgs
- where pcn signalling doesn't fate share with existing resource
signalling, eg a special pcn msg carries pcn info. 

They key difference is that the first assumes there is an existing
resource signalling mechanism, whilst the second needs reliability on
the special pcn msg

Tom, I don't see you difference (2) as significant - I think that the
admission decision can be made at the ingress or egress for either [the
case of centralised decision point makes no difference; if you want to
fate share pcn signalling & resource signalling, then clearly the latter
must go through the centralised node]

for Flow termination
Signalling of pcn info can use the existing resource signalling - if the
latter allows asynchronous msgs. So for resource signalling protocols
that don't support this, then you have to use a special psn msg 

Best wishes,
phil
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 07 October 2009 00:44
To: Tom Taylor
Cc: pcn; Briscoe,RJ,Bob,XVR9 BRISCORJ R; Eardley,PL,Philip,DEE1 R
Subject: Re: [PCN] Piggybacking -- a new edge behaviour

Hi Tom,

Kind regards,

    Michael

---

From: Tom Taylor <[email-masked]>
Date: Mon, 12 Oct 2009 16:09:10 -0400

Please see below.

> must go through the centralised node]
[PTT] No. You are confounding the per-flow decision with the reporting of an 
admission state that conditions that decision. The actual decision whether to 
admit a specific flow can be made at the egress node only when resource 
signalling is being used. Otherwise it MUST be made elsewhere.

> that don't support this, then you have to use a special psn msg 
...

---

From: <[email-masked]>
Date: Tue, 13 Oct 2009 09:04:39 +0100

> must go through the centralised node]
[PTT] No. You are confounding the per-flow decision with the reporting
of an 
admission state that conditions that decision. The actual decision
whether to 
admit a specific flow can be made at the egress node only when resource 
signalling is being used. Otherwise it MUST be made elsewhere.

[phil] don't agree with this MUST - you can make the decision wherever
and this then sets what signalling msgs are needed. 
But sure, I think it's fine for the i-d covering the case without the
resource signalling to assume that the actual decision is not at the
egress.