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

[Michael Menth <menth at informatik.uni-wuerzburg.de>]

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