Subject: [PCN] probing functionality

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 09 Nov 2007 12:41:16 +0000

Hi all

Another method that can be used for PCN probing can be applied as follows.
The probe packets are generated by the PCN_ingress_nodes in the following
way.
A probe packet belonging to a certain micro-flow is generated using the
same 5 touple (source, destination IP address, source, destination ports,
protocol number) as the packets belonging to the same micro-flow. In
addition to this the PCN_ingress_node has to set the Router Alert IP
option on the probe packet. In this way all the PCN_interior_node will
have to observe the received probe packets.

Thus if a PCN_interior_node receives a probe packet then, due to the
Router Alert option it has to handle it differently then the user packets.
The PCN_interior_node has to PCN_mark the probe packet if it is operating
in admission control state (or flow termination state). Otherwise the
probe packet remains unmarked.

Best regards,
Georgios

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 13 Nov 2007 09:30:33 +0100

Georgios,

maybe I'm wrong, but I think you were the one to mention that 
probing could be a single packet, which would be the RSVP 
PATH message. The RSVP path message or a similar message of 
another protocol is transmitted from PCN ingress node to PCN 
egress node anyway prior to flow admission and it probably 
has the RAO set. If we rely on ECMP being based on addresses, 
it travels the way of the flow to be admitted.

Couldn't we use this single signaling packet to indicate 
pending congestion to an egress node? Two cases may apply:

1)on IP, the packet could be PCN marked by the congested 
  router once it notes, that the packet is to be forwarded 
  across a congested PCN interface. It is forwarded on 
  slow path due to RAO, special marking shouldn't be an 
  issue.

2)if RAO can't be applied, because slow path processing is 
  not desired within the PCN domain or it is impossible 
  (as in the MPLS case), then this signaling packet should 
  be marked once traffic approaches the termination 
  threshold. That means that once the termination threshold 
  is approached, all packets crossing a link must be 
  pre-congestion marked. 

None of the above two requires special probings to be build 
and allows PCN at least make entering the termination 
mode due to over admission improbable, also if ECMP is present. 
Ramp marking remains an applicable option in the admission 
threshold region. 

It is a requirement however, that source and destination 
address of the flow to be admitted are used for signaling 
between PCN ingress and egress node prior to flow admission.

Your suggestion addresses point 1) above, but you don't 
explicitely suggest to use RSVP below. Thus your packet always 
travels the same path as the flow to be admitted, but it no 
longer must be a signaling packet. I'd prefer to stick with 
the RSVP/NSIS packet approach and suggest recommending to
restrict ECMP to hash on addresses if PCN and ECMP are 
operated in a single domain. 

Regards,

Rudiger

|-----Original Message-----
|From: Georgios Karagiannis [mailto:[email-masked]]
|Sent: Friday, November 09, 2007 1:41 PM
|To: [email-masked]
|Subject: [PCN] probing functionality
|
|
|Hi all
|
|Another method that can be used for PCN probing can be applied 
|as follows.
|The probe packets are generated by the PCN_ingress_nodes in 
|the following
|way.
|A probe packet belonging to a certain micro-flow is generated using the
|same 5 touple (source, destination IP address, source, 
|destination ports,
|protocol number) as the packets belonging to the same micro-flow. In
|addition to this the PCN_ingress_node has to set the Router Alert IP
|option on the probe packet. In this way all the PCN_interior_node will
|have to observe the received probe packets.
|
|Thus if a PCN_interior_node receives a probe packet then, due to the
|Router Alert option it has to handle it differently then the 
|user packets.
|The PCN_interior_node has to PCN_mark the probe packet if it 
|is operating
|in admission control state (or flow termination state). Otherwise the
|probe packet remains unmarked.
|
|Best regards,
|Georgios
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Michael Menth <[email-masked]>
Date: Tue, 13 Nov 2007 19:14:52 +0100

Hi Ruediger,

what you describe is how we also think that probing could be realized 
when RSVP or some other signalling protocol is used end-to-end.

The initial RSVP PATH message is used for probing: if the PATH message 
arrives at the PCN egress and is not marked, the PCN egress node 
proceeds as a usual RSVP node and forwards the message further 
downstream. But if the message is marked, the PCN egress node sends back 
a PATHERR message to reject the flow. Conversely, if a RESV message 
returns, this implies that the PATH message was not marked at the PCN 
egress node. Therefore, the PCN ingress node can accept the new flow 
when it receives a RESV message.

In 3sm and CL, all packets are marked with "admission-stop" when the PCN 
traffic rate exceeds the admissible rate of a link. If the RSVP control 
messages are transmitted as PCN traffic, they are also marked with 
"admission-stop" in case of pre-congestion. Therefore, no special 
treatment of such probing traffic is needed inside the PCN domain.

Regards,

    Michael

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 14 Nov 2007 08:57:43 +0100

Hello Michael,

to complete the statements on RSVP, if signaling messages carry 
the addresses of the flows they reserve resources for, also the 
refreshes travel the same path as the data. So they can be used 
to identify the flows already admitted, should termination be 
pending. This is a simple way to identify admitted flows in the
presence of ECMP and pre-congestion. This won't work with 
aggregated reservations or summary refreshes, obviously.

I wouldn't call that "probing", if it is just based on standard 
signaling messages, which are transmitted anyway. 

Regards,

Rudiger

|-----Original Message-----
|From: Michael Menth [mailto:[email-masked]]
|Sent: Tuesday, November 13, 2007 7:15 PM
|To: Geib, Rüdiger
|Cc: [email-masked]
|Subject: Re: [PCN] probing functionality
|
|
|Hi Ruediger,
|
|what you describe is how we also think that probing could be realized 
|when RSVP or some other signalling protocol is used end-to-end.
|
|The initial RSVP PATH message is used for probing: if the PATH message 
|arrives at the PCN egress and is not marked, the PCN egress node 
|proceeds as a usual RSVP node and forwards the message further 
|downstream. But if the message is marked, the PCN egress node 
|sends back 
|a PATHERR message to reject the flow. Conversely, if a RESV message 
|returns, this implies that the PATH message was not marked at the PCN 
|egress node. Therefore, the PCN ingress node can accept the new flow 
|when it receives a RESV message.
|
|In 3sm and CL, all packets are marked with "admission-stop" 
|when the PCN 
|traffic rate exceeds the admissible rate of a link. If the 
|RSVP control 
|messages are transmitted as PCN traffic, they are also marked with 
|"admission-stop" in case of pre-congestion. Therefore, no special 
|treatment of such probing traffic is needed inside the PCN domain.
|
|Regards,
|
|    Michael
|
|
|Geib, Ruediger wrote:
|> Georgios,
|>
|> maybe I'm wrong, but I think you were the one to mention that 
|> probing could be a single packet, which would be the RSVP 
|> PATH message. The RSVP path message or a similar message of 
|> another protocol is transmitted from PCN ingress node to PCN 
|> egress node anyway prior to flow admission and it probably 
|> has the RAO set. If we rely on ECMP being based on addresses, 
|> it travels the way of the flow to be admitted.
|>
|> Couldn't we use this single signaling packet to indicate 
|> pending congestion to an egress node? Two cases may apply:
|>
|> 1)on IP, the packet could be PCN marked by the congested 
|>   router once it notes, that the packet is to be forwarded 
|>   across a congested PCN interface. It is forwarded on 
|>   slow path due to RAO, special marking shouldn't be an 
|>   issue.
|>
|> 2)if RAO can't be applied, because slow path processing is 
|>   not desired within the PCN domain or it is impossible 
|>   (as in the MPLS case), then this signaling packet should 
|>   be marked once traffic approaches the termination 
|>   threshold. That means that once the termination threshold 
|>   is approached, all packets crossing a link must be 
|>   pre-congestion marked. 
|>
|> None of the above two requires special probings to be build 
|> and allows PCN at least make entering the termination 
|> mode due to over admission improbable, also if ECMP is present. 
|> Ramp marking remains an applicable option in the admission 
|> threshold region. 
|>
|> It is a requirement however, that source and destination 
|> address of the flow to be admitted are used for signaling 
|> between PCN ingress and egress node prior to flow admission.
|>
|> Your suggestion addresses point 1) above, but you don't 
|> explicitely suggest to use RSVP below. Thus your packet always 
|> travels the same path as the flow to be admitted, but it no 
|> longer must be a signaling packet. I'd prefer to stick with 
|> the RSVP/NSIS packet approach and suggest recommending to
|> restrict ECMP to hash on addresses if PCN and ECMP are 
|> operated in a single domain. 
|>
|> Regards,
|>
|> Rudiger
|>
|> |-----Original Message-----
|> |From: Georgios Karagiannis [mailto:[email-masked]]
|> |Sent: Friday, November 09, 2007 1:41 PM
|> |To: [email-masked]
|> |Subject: [PCN] probing functionality
|> |
|> |
|> |Hi all
|> |
|> |Another method that can be used for PCN probing can be applied 
|> |as follows.
|> |The probe packets are generated by the PCN_ingress_nodes in 
|> |the following
|> |way.
|> |A probe packet belonging to a certain micro-flow is 
|generated using the
|> |same 5 touple (source, destination IP address, source, 
|> |destination ports,
|> |protocol number) as the packets belonging to the same micro-flow. In
|> |addition to this the PCN_ingress_node has to set the Router Alert IP
|> |option on the probe packet. In this way all the 
|PCN_interior_node will
|> |have to observe the received probe packets.
|> |
|> |Thus if a PCN_interior_node receives a probe packet then, due to the
|> |Router Alert option it has to handle it differently then the 
|> |user packets.
|> |The PCN_interior_node has to PCN_mark the probe packet if it 
|> |is operating
|> |in admission control state (or flow termination state). 
|Otherwise the
|> |probe packet remains unmarked.
|> |
|> |Best regards,
|> |Georgios
|> |
|> |
|> |_______________________________________________
|> |PCN mailing list
|> [email-masked]
|> |https://www1.ietf.org/mailman/listinfo/pcn
|> |
|>
|>
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.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://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Michael Menth <[email-masked]>
Date: Wed, 14 Nov 2007 09:03:23 +0100

Hi Ruediger,

Geib, Ruediger wrote:
> aggregated reservations 
True - this is a solution only for end-to-end RSVP. What you mention 
above would work with some kind of tunneling (MPLS, IP-in-IP). 
Therefore, we probably need to look at different deployment scenarios.

> or summary refreshes, obviously.
>   
As long as the first PATH message and RESV message are transmitted as 
single messages I don't see a problem.

> signaling messages, which are transmitted anyway. 
Yes, this is rather lightweight in the sense that it doesn't require 
extra messages. Therefore, one even hesitates to call it probing. 
Nevertheless, the PATH message is reused for probing and fulfills this 
function.

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Nov 2007 15:55:45 +0100

Hi Michael and Rudieger

You canb use the method that I have proposed not only on user packets, but
also
on signaling messages, e.g., RSVP PATH or NSIS RESERVE, as long 
as:
 * they follow as much as possible the path followed by the user packets,
 * they can be associated with a certain flow and
 * these signaling messages will be 
   used by a a router that does not support the RSVP or NSIS protocol suite.
   This could be done if e.g., these signaling messages carry a Router Alert
option!

Best Regards,
Georgios

> -----Original Message-----
> From: Michael Menth [mailto:[email-masked]] 
> Sent: woensdag 14 november 2007 9:03
> To: Geib, Ruediger
> Cc: [email-masked]
> Subject: Re: [PCN] probing functionality
> 
> Hi Ruediger,
> 
> Geib, Ruediger wrote:
> > Hello Michael,
> >
> > to complete the statements on RSVP, if signaling messages carry the 
> > addresses of the flows they reserve resources for, also the 
> refreshes 
> > travel the same path as the data. So they can be used to 
> identify the 
> > flows already admitted, should termination be pending. This is a 
> > simple way to identify admitted flows in the presence of ECMP and 
> > pre-congestion. This won't work with aggregated reservations
> True - this is a solution only for end-to-end RSVP. What you 
> mention above would work with some kind of tunneling (MPLS, 
> IP-in-IP). 
> As long as the first PATH message and RESV message are 
> transmitted as single messages I don't see a problem.
> 
> Yes, this is rather lightweight in the sense that it doesn't 
> require extra messages. Therefore, one even hesitates to call 
> it probing. 
> Nevertheless, the PATH message is reused for probing and 
> fulfills this function.
> 
> Regards,
> 
>     Michael
> 
> > Regards,
> >
> > Rudiger
> >
> > |The initial RSVP PATH message is used for probing: if the PATH 
> > |message arrives at the PCN egress and is not marked, the 
> PCN egress 
> > |node proceeds as a usual RSVP node and forwards the 
> message further 
> > |downstream. But if the message is marked, the PCN egress 
> node sends 
> > |back a PATHERR message to reject the flow. Conversely, if a RESV 
> > |message returns, this implies that the PATH message was 
> not marked at 
> > |the PCN egress node. Therefore, the PCN ingress node can 
> accept the 
> > |new flow when it receives a RESV message.
> > |
> > |traffic rate exceeds the admissible rate of a link. If the RSVP 
> > |control messages are transmitted as PCN traffic, they are 
> also marked 
> > |with "admission-stop" in case of pre-congestion. Therefore, no 
> > |special treatment of such probing traffic is needed inside the PCN 
> > |domain.
> > |
> > |Regards,
> > |
> > |    Michael
> > |
> > |
> > |Geib, Ruediger wrote:
> > |> Georgios,
> > |>
> > |> probing could be a single packet, which would be the RSVP PATH 
> > |> message. The RSVP path message or a similar message of another 
> > |> protocol is transmitted from PCN ingress node to PCN egress node 
> > |> anyway prior to flow admission and it probably has the 
> RAO set. If 
> > |> we rely on ECMP being based on addresses, it travels the 
> way of the 
> > |> flow to be admitted.
> > |>
> > |> Couldn't we use this single signaling packet to indicate pending 
> > |> congestion to an egress node? Two cases may apply:
> > |>
> > |> None of the above two requires special probings to be build and 
> > |> allows PCN at least make entering the termination mode 
> due to over 
> > |> admission improbable, also if ECMP is present.
> address of 
> > |> the flow to be admitted are used for signaling between 
> PCN ingress 
> > |> and egress node prior to flow admission.
> > |>
> explicitely 
> > |> suggest to use RSVP below. Thus your packet always 
> travels the same 
> > |> path as the flow to be admitted, but it no longer must be a 
> > |> signaling packet. I'd prefer to stick with the RSVP/NSIS packet 
> > |> approach and suggest recommending to restrict ECMP to hash on 
> > |> addresses if PCN and ECMP are operated in a single domain.
> > |>
> > |> Regards,
> > |>
> > |> Rudiger
> > |>
> > |> |Another method that can be used for PCN probing can be 
> applied as 
> > |> |follows.
> > |> |The probe packets are generated by the PCN_ingress_nodes in the 
> > |> |following way.
> destination 
> > |> |ports, protocol number) as the packets belonging to the same 
> > |> |micro-flow. In addition to this the PCN_ingress_node has to set 
> > |> |the Router Alert IP option on the probe packet. In this way all 
> > |> |the
> > |PCN_interior_node will
> > |> |Thus if a PCN_interior_node receives a probe packet 
> then, due to 
> > |> |the Router Alert option it has to handle it differently 
> then the 
> > |> |user packets.
> > |> |The PCN_interior_node has to PCN_mark the probe packet if it is 
> > |> |operating in admission control state (or flow 
> termination state).
> > |Otherwise the
> > |Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> > |Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> > |room B206
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: Lars Eggert <[email-masked]>
Date: Mon, 19 Nov 2007 10:49:49 +0200

> have to observe the received probe packets.

FYI, during the IETF last call and the following IESG discussion  
around NSIS GIST, routing area folks claimed that NSIS' use of RAO was  
problematic. You probably want to ask some routing folks what they  
think of using RAO for this purpose.

Lars