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

[<Ruediger.Geib at telekom.de>]

Tom,

I agree to your proposal.

Regards, Ruediger 

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

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

_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn