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

[<philip.eardley at bt.com>]

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:menth at informatik.uni-wuerzburg.de] 
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,

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:
>
> (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

-- 
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:menth at informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn