Subject: Re: [PCN] draft-ietf-pcn-architecture-03

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 3 Mar 2008 10:26:23 +0100

Hi Phil

Yes agree, rsvp hop is being edge to edge & no rsvp processing on the 
interior nodes occurs. But what I meant is that in the case of the Intserv
over Diffserv scenario,
RSVP could be used as the Intserv signaling protocol. This means that the
RSVP PATH message will be 
used/processed by PCN-ingress-nodes and PCN-egress-nodes, which are Intserv
aware. Furthermore, 
it is important to note that the RSVP PATH carries a Router Alert option.
Now if the RSVP PATH 
message is used within the PCN domain as a probe packet, then the only 
additional PCN functionality in the PCN-interior-nodes, is to use
the RAO bits carried by the probe packet (i.e., RSVP PATH) for detection
rather than 
an additional ECN/DSCP code.
Note that the PCN-Interior-nodes are not Intserv aware, but only PCN aware.

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 29 februari 2008 12:29
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> 
> Whoah! The Intserv or diffserv model was always(*) about the 
> rsvp hop being edge to edge & no rsvp processing on the 
> interior nodes. (*)ie right back to the first architecture 
> draft way before the PCN wg.
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[email-masked]]
> > Sent: 29 February 2008 09:24
> > To: Eardley,PL,Philip,CXR9 R; [email-masked]; 
> [email-masked] 
> > wuerzburg.de
> > Cc: [email-masked]
> > Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> > 
> > Hi Phil
> > 
> > Regarding the below comment!
> > 
> > > in terms of encoding, it does have a second encoding, but it uses 
> > > RAO bits rather than ECN/DSCP bits.
> > >
> > > I worry a bit about security attacks (because probe pkts 
> can now be
> > > identified) and about deploability barrier (will operators deploy 
> > > something that slows all their core routers - after all 
> we claimed 
> > > one advantage of PCN over hop-by-hop rsvp is that your 
> core routers 
> > > are really simple, don't have to do any difficult processing...
> > 
> > In the architecture draft we mention that Intserv over 
> Diffserv is one
> of
> > the scenarios that could be
> > supported by PCN. In this case I assume that RSVP will be 
> used as the 
> > Intserv signaling protocol.
> > RSVP PATH carries already a Router Alert option.
> > The only additional functionality in the 
> PCN-interior-nodes, is to use
> the
> > RAO bits for detection
> > rather than an additional ECN/DSCP code.
> > 
> > Best regards,
> > Georgios
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of [email-masked]
> > > Sent: donderdag 28 februari 2008 19:53
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
> > >
> > > Hi
> > >
> > > Thanks for clarifying Georgios. interesting idea.
> > >
> > > Just to go back to the basic reason why single marking's 
> attractive.
> > > [1] single marking behaviour on interior routers [2] only single 
> > > encoding needed
> > >
> > > your idea at first sight has just one marking behaviour, 
> ie excess 
> > > rate marking. Indeed, it only has one token bucket.
> > > However, it does have extra code/complexity in order to 
> do threshold 
> > > marking for probe pkts, and this involves the pkt being 
> processed on 
> > > the slow path within a router. I guess this complexity is for pkt 
> > > classification & PCN-encoding, rather than for the PCN-metering 
> > > function.
> > >
> > > in terms of encoding, it does have a second encoding, but it uses 
> > > RAO bits rather than ECN/DSCP bits.
> > >
> > > I worry a bit about security attacks (because probe pkts 
> can now be
> > > identified) and about deploability barrier (will operators deploy 
> > > something that slows all their core routers - after all 
> we claimed 
> > > one advantage of PCN over hop-by-hop rsvp is that your 
> core routers 
> > > are really simple, don't have to do any difficult processing...
> > >
> > > phil
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of
> > > Anna
> > > > Charny (acharny)
> > > > Sent: 28 February 2008 16:08
> > > > To: [email-masked]
> > > > Cc: pcn
> > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
> > > >
> > > > Hi Michael,
> > > >
> > > > Ah - that makes perfect sense. Thank you for the 
> concise summary.
> > > >
> > > > Anna
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Menth [mailto:[email-masked]]
> > > > > Sent: Thursday, February 28, 2008 10:51 AM
> > > > > To: Anna Charny (acharny)
> > > > > Cc: Lars Eggert; pcn
> > > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03
> > > > >
> > > > > Hi Anna,
> > > > >
> > > > > Anna Charny (acharny) wrote:
> > > > > > Hi Michael,
> > > > > >
> > > > > > You lost me on this.  The discussion seems to be centered
> > > > > around the
> > > > > > complexities of appropriately forwarding and processing
> > > > > probe packets
> > > > > > in the core.  What exactly does excess rate marking has to
> > > > > do with it?
> > > > > > (I do understand the point that excess rate marking needs
> > > > > more probes
> > > > > > to work reliably than threshold-vased/aka
> > > > > vertuall-queue-based marking
> > > > > > - I just do not see the connection of this point to the
> > > > > discussion it
> > > > > > seems to relate to).
> > > > > >
> > > > >
> > > > > Georgios proposes to do excess rate marking and to avoid
> multiple
> > > > > probes, he wants to make sure that probe packets are always 
> > > > > AM-marked when a link is precongested with regard to the
> > > admissible
> > > > > rate. He solves this problem using the router alert 
> option (RAO) 
> > > > > taking packets off the fast path. This solves the problem
> > > you have
> > > > > described above (which is caused by excess rate marking), but 
> > > > > introduces the problem of RAO.
> > > > > That impacts the forwarding of the packets as they 
> need special 
> > > > > handling by the routers. The origin of this thread 
> was that the 
> > > > > architecture draft said that all pcn packets should be treated
> in
> > > > > the same way by PCN nodes which is no longer the case 
> for normal 
> > > > > data packet and PCN packets.
> > > > >
> > > > > Regards,
> > > > >
> > > > >     Michael
> > > > >
> > > > > > If I am missing your point (or the point of the discussion)
> > > > > - which is
> > > > > > quite possible as I am reading the thread backwards - I
> > > would much
> > > > > > appreciate a clarification.
> > > > > >
> > > > > > Anna
> > > > > >
> > > > > >
> > > > > >> -----Original Message-----
> > > > > >> From: [email-masked] [mailto:[email-masked]]
> > > > > On Behalf Of
> > > > > >> Michael Menth
> > > > > >> Sent: Thursday, February 28, 2008 5:50 AM
> > > > > >> To: Lars Eggert
> > > > > >> Cc: pcn
> > > > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03
> > > > > >>
> > > > > >> Hi Lars,
> > > > > >>
> > > > > >> I just want to point out that this complexity is not due
> > > > > to probing
> > > > > >> itself but due to the use of excess rate marking for
> admission
> > > > > >> control.
> > > > > >> There is no such increased complexity if probing 
> is done in 
> > > > > >> combination with exhaustive (threshold) marking for
> > > > > admission control.
> > > > > >>
> > > > > >> Regards,
> > > > > >>
> > > > > >>     Michael
> > > > > >>
> > > > > >> Lars Eggert wrote:
> > > > > >>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> I'm not sure if I have fully digested this yet, but it
> > > > > >>>
> > > > > >> seems like this
> > > > > >>
> > > > > >>> proposal defines different semantics for what the PCN
> > > > > marks mean to
> > > > > >>> both the interior and egress nodes, depending on whether a
> > > > > >>>
> > > > > >> packet is a
> > > > > >>
> > > > > >>> probe packet or not. That seems to add significant
> complexity.
> > > > > >>>
> > > > > >>> Lars
> > > > > >>>
> > > > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>> Hi Phil
> > > > > >>>>
> > > > > >>>> Sorry for not being clear!
> > > > > >>>>
> > > > > >>>> As you know if ECMP routing is used then this might cause
> > > > > >>>>
> > > > > >> problems on
> > > > > >>
> > > > > >>>> the way of how admission control and flow termination
> > > > > >>>>
> > > > > >> algorithms are
> > > > > >>
> > > > > >>>> operating.
> > > > > >>>>
> > > > > >>>> The ECMP problem is related to the fact that flows can
> > > > > belong to a
> > > > > >>>> certain ingress-egress-aggregate, which is maintained at
> > > > > >>>>
> > > > > >> the ingress
> > > > > >>
> > > > > >>>> adn egress and that operates in admission control
> > > state or flow
> > > > > >>>> termination state, but that due to the ECMP routing they
> are
> > > not
> > > > > >>>> passing through the congested node.
> > > > > >>>>
> > > > > >>>> Any measures that are taken on such flows will not solve
> the
> > > > > >>>> congestion problem, since such flows are not contributing
> > > > > >>>>
> > > > > >> and causing
> > > > > >>
> > > > > >>>> the congestion in the PCN-interior-node.
> > > > > >>>>
> > > > > >>>> Now when probing is used this problem can be solved
> > > as follows.
> > > > > >>>> When a PCN-interior-node is congested it MUST
> > > > > PCN_marking encode a
> > > > > >>>> probe packet.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> Thus if an egress operates, for a certain
> > > > > >>>>
> > > > > >> ingress-egress-agrregate in
> > > > > >>
> > > > > >>>> admission control state and it receives a probe packet
> > > > > >>>>
> > > > > >> which belongs
> > > > > >>
> > > > > >>>> to a flow associated with the same
> > > > > >>>>
> > > > > >> ingress-egress-agrregate AND the
> > > > > >>
> > > > > >>>> probe packet is PCN_marking encoded, then the 
> egress knows
> > > > > >>>>
> > > > > >> for sure
> > > > > >>
> > > > > >>>> that the probe packet passed through one or more 
> congested 
> > > > > >>>> PCN-interior-nodes. In this case the probe packet, and
> > > > > >>>>
> > > > > >> thus also the
> > > > > >>
> > > > > >>>> requiesting flow can be rejected.
> > > > > >>>>
> > > > > >>>> If an egress operates, for a certain
> ingress-egress-agrregate
> > > in
> > > > > >>>> admission control state and it receives a probe packet
> > > > > >>>>
> > > > > >> which belongs
> > > > > >>
> > > > > >>>> to a flow associated with the same
> > > > > >>>>
> > > > > >> ingress-egress-agrregate AND the
> > > > > >>
> > > > > >>>> probe packet is marked as not congested PCN, then the
> > > > > egress knows
> > > > > >>>> for sure that the probe packet HAS NOT PASSED through a
> > > > > congested
> > > > > >>>> PCN-interior-node due to e.g., used ECMP routing. In
> > > > > this case the
> > > > > >>>> probe packet can be accepted, since this flow, even it
> > > > > >>>>
> > > > > >> belongs to the
> > > > > >>
> > > > > >>>> ingress-egress-aggergate that operates in admission
> > > > > >>>>
> > > > > >> control, is not
> > > > > >>
> > > > > >>>> contributing and causing the congestion in the
> > > PCN-interior-node.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> Okay, but why one should provide the possibility to
> > > > > PCN-interior-
> > > > > >>>> nodes to distinguish between probe packets and other PCN
> > > > > >>>>
> > > > > >> aware user
> > > > > >>
> > > > > >>>> packets?
> > > > > >>>>
> > > > > >>>> This is related to which admission control and flow
> > > termination
> > > > > >>>> algorithms and encodings are used in the
> PCN-interior-nodes.
> > > > > >>>>
> > > > > >>>> If an algorithm uses one encoding state for admission
> > > > > control and
> > > > > >>>> another encoding state for flow termination then probably
> > > > > >>>>
> > > > > >> it is not
> > > > > >>
> > > > > >>>> required to provide the possibility to 
> PC_interior-node to 
> > > > > >>>> distinguish between probe packets and PCN aware user
> packets.
> > > > > >>>> This is because when the PCN-interior-node that operates
> > > > > >>>>
> > > > > >> in admission
> > > > > >>
> > > > > >>>> control state will AM (admission control encoding state)
> > > > > >>>>
> > > > > >> encode all
> > > > > >>
> > > > > >>>> packets, i.e., probe packets and user packets.
> > > > > >>>>
> > > > > >>>> If an algorithm uses only one encoding state for
> > > > > admission control
> > > > > >>>> and flow termionation, such as the ones used in the
> > > > > single marking
> > > > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut
> > > > > be able to
> > > > > >>>> distinguish between probe packets and user data packets.
> > > > > >>>>
> > > > > >>>> This is because both algorithms SM and LC-PCN are
> > > > > encoding packets
> > > > > >>>> proportionaly to the excess rate.
> > > > > >>>> This means that when the PCN-interior-node opetrates in
> > > > > admission
> > > > > >>>> control state it will not SM mark all packets that
> > > are passing
> > > > > >>>> through the node, but only a proportion that is needed to
> > > > > >>>>
> > > > > >> represent
> > > > > >>
> > > > > >>>> the excess rate. Thus if the PCN-interior-node will not
> > > > > >>>>
> > > > > >> distinguish
> > > > > >>
> > > > > >>>> between the probe packets and other PCN aware packets,
> > > > > >>>>
> > > > > >> then it is not
> > > > > >>
> > > > > >>>> certain that the probe packet will be SM marked when the 
> > > > > >>>> PCN-interior-node operates in admission control state.
> > > > > >>>> Now, if the probe packets carry a Router Alert option,
> > > > > and when in
> > > > > >>>> Admission control state, the PCN-interior-node marks all
> > > > > >>>>
> > > > > >> packets that
> > > > > >>
> > > > > >>>> are carrying a Router Alert option, then the probe packet
> > > > > >>>>
> > > > > >> will be for
> > > > > >>
> > > > > >>>> sure marked.
> > > > > >>>>
> > > > > >>>> Hope that this clarifies your question!
> > > > > >>>>
> > > > > >>>> Best regards,
> > > > > >>>> Georgios
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: [email-masked] 
> [mailto:[email-masked]]
> > > > > >>>>> Sent: dinsdag 26 februari 2008 18:16
> > > > > >>>>> To: [email-masked]; [email-masked]
> > > > > >>>>> Cc: [email-masked]
> > > > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> > > > > >>>>>
> > > > > >>>>> Sorry, to repeat:
> > > > > >>>>>
> > > > > >>>>> I still have not the foggiest idea why on earth someone
> > > > > >>>>>
> > > > > >> would want
> > > > > >>
> > > > > >>>>> or need or be interested in the interior node handling
> > > > > probe pkts
> > > > > >>>>> differently from the way it handles probe pkts.
> > > > > >>>>>
> > > > > >>>>> So far you have answered a different question, about
> whether
> > > it
> > > > > >>>>> would be possible for someone to devise pcn so that an
> > > > > >>>>>
> > > > > >> interior node
> > > > > >>
> > > > > >>>>> could distinguish probe pkts from data pkts. As you
> > > > > say, a router
> > > > > >>>>> alert option could indeed be used.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> -----Original Message-----
> > > > > >>>>>> From: Georgios Karagiannis
> [mailto:[email-masked]]
> > > > > >>>>>> Sent: 26 February 2008 17:06
> > > > > >>>>>> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> > > > > >>>>>> Cc: [email-masked]
> > > > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> > > > > >>>>>>
> > > > > >>>>>> Hi Phil
> > > > > >>>>>>
> > > > > >>>>>> * Regarding Routing NOT,
> > > > > >>>>>> * Regarding scheduling, NOT
> > > > > >>>>>> * Regarding PCN_marking, it could be handled 
> differently:
> > > > > >>>>>>
> > > > > >>>>>>  ** if excess rate marking is used AND the
> > > PCN-interior-node
> > > is
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> congested
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> AND
> > > > > >>>>>>     the probe packet contains the ROUTER ALERT option
> THEN
> > > > > >>>>>>     the probe packet can be distinguished from 
> the other
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> PCN packets,
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>     and therefore it will be for sure PCN_marking
> encoded.
> > > > > >>>>>>
> > > > > >>>>>>  ** if excess rate marking is used AND the
> > > PCN-interior-node
> > > is
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> congested
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> AND
> > > > > >>>>>>     the probe packet DOES NOT contain the ROUTER
> > > ALERT option
> > > > > >>>>>>     THEN this MIGHT be PCN_marking encoded, or it MIGHT
> not
> > > be
> > > > > >>>>>> PCN_marking encoded. This depends
> > > > > >>>>>>     on whether this probe packet is selected 
> to represent
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> the excess
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> rate, or is not selected.
> > > > > >>>>>>
> > > > > >>>>>> Best regards,
> > > > > >>>>>> Georgios
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>> -----Original Message-----
> > > > > >>>>>>> From: [email-masked]
> [mailto:[email-masked]]
> > > > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45
> > > > > >>>>>>> To: [email-masked]; [email-masked]
> > > > > >>>>>>> Cc: [email-masked]
> > > > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03
> > > > > >>>>>>>
> > > > > >>>>>>> But why would the interior node *need* to 
> distinguish it
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> from other
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> pcn pkts?
> > > > > >>>>>>>
> > > > > >>>>>>> And even if you have got router alert, the 
> architecture
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> draft says:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> "must be handled the same as (ordinary data)
> PCN-packets,
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> in terms
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> of routing, scheduling and PCN-marking."
> > > > > >>>>>>> Even though your router alert's got it in slow path,
> will
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>> it handle
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> it any differently in terms of routing scehdulign &
> > > > > pcn-marking?
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>> _______________________________________________
> > > > > >>>> PCN mailing list
> > > > > >>>> [email-masked]
> > > > > >>>> https://www.ietf.org/mailman/listinfo/pcn
> > > > > >>>>
> > > > > >>>>
> > > > > >>> _______________________________________________
> > > > > >>> 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/888-6644, fax: (+49)-931/888-6632 
> > > > > >> mailto:[email-masked]
> > > > > >> http://www3.informatik.uni-wuerzburg.de/research/ngn
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> 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/888-6644, fax: (+49)-931/888-6632 
> > > > > mailto:[email-masked]
> > > > > http://www3.informatik.uni-wuerzburg.de/research/ngn
> > > > >
> > > > >
> > > > _______________________________________________
> > > > PCN mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/pcn
> > > _______________________________________________
> > > PCN mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/pcn
> > >
> > 
> 

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