Message-ID: <47150885.70606@informatik.uni-wuerzburg.de>
Date: Tue, 16 Oct 2007 20:52:53 +0200
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: philip.eardley@bt.com
Subject: Re: [PCN] Architecture draft - probing section & general updates.
References: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC5CD@E03MVZ1-UKDY.domain1.systemhost.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: pcn@ietf.org
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
Errors-To: pcn-bounces@ietf.org

Hi Phil,

I like your text as it reflects the current ideas about probing. It=20
nicely identifies the benefits and also the difficulties (that we were=20
always aware of!) of the two different types of probing. My view is to=20
first solve the easy tasks and then see whether there is a solution to=20
the more challenging objectives. It is good to have this section in the=20
architecture draft that the benefits of probing do not get lost on the=20
way to a first simple system.

Regards,

Michael


philip.eardley@bt.com wrote:
>
> Hi,
>
> There was quite a discussion about the probing section of the=20
> Architecture draft recently, draft-ietf-pcn-architecture-00. This=20
> showed to me that it needed a re-write, which I=92ve attempted.
>
> One thing that struck me reading the discussion was that there really=20
> seem to be 2 uses of probing. The current draft tries to talk about=20
> them as though they=92re two aspects of the same thing; in the text=20
> below I=92ve tried instead to talk about them separately =96 because I=20
> think they=92re really quite different.
>
> The first uses probing to test the ingress-egress-aggregate, the=20
> second uses probing is to test a particular ECMP path.
>
> The first uses probe pkts addressed to the PCN-egress-node, the second=20
> uses probe pkts addressed to the destination end node [so they follow=20
> the same ECMp path as the data pkts would do]
>
> The first has no problem stopping probe pkts leaking out of the=20
> PCN-domain [because they=92re addressed to the PCN-egress-node] whilst=20
> the second has to think carefully about this [how the PCN-egress-node=20
> can easily identify pkts, but the ECMP algos are unaffected by the=20
> =93flag =3D probe pkt=94]
>
> The first would probably be used by people who envisage probing rarely=20
> being used (most ingress-egress-aggregates always have traffic), the=20
> second is probably favoured by people who would actually probe on=20
> every call admission attempt [esp people who have it in mind to have=20
> PCN operating in parts of network with lower capacity links ie the=20
> multiple flows (aggregation) assumption doesn=92t hold]. (There are=20
> plenty of other scenarios which I=92m not commenting on!)
>
> The first has a less clear benefit to me (it doesn=92t seem that much=20
> better than the easy alternative - just admit the =91first=92 flow into=
 an=20
> =91empty=92 ingress-egress-aggregate, and take the chance it causes flo=
ws=20
> to be terminated or pkts to be dropped). The second has a clearer=20
> benefit to me, in some scenarios (you test the actual ECMP path the=20
> flow would take.)
>
> The first probing approach (ie tests the ingress-egress-aggregate)=20
> seems to me quite simple to define, but the second much harder [need=20
> to work out how to stop probes leaking out of PCN-domain and how to=20
> flag a probe to minimise interactions with ECMP].
>
> Personally I think that in the short term (say until Christmas) our=20
> objective is to start converging on the router=92s PCN-marking behaviou=
r=20
> (algorithm & encoding) =96 so it isn=92t necessary to talk about the=20
> details of probing at the moment. However, as part of the algorithm=20
> discussion it is relevant to note (as Michael has already pointed out)=20
> that excess-rate-marking algorithm is less suitable than a=20
> threshold-marking algo from a probing perspective (at least you have=20
> to send a lot more probe pkts to get an accurate picture of the=20
> pre-congestion level). (of course it=92s only one factor when we choose=
=20
> the algo.)
>
> Anyway, here=92s the proposed revised sub-section 5.5 about probing =96=
=20
> please comment /shout if you don=92t like it:-
>
> ****
>
> Probing functions are optional, and can be used for admission control.
>
> PCN=92s admission control, as described so far, is essentially a=20
> reactive mechanism where the PCN-egress-node monitors the=20
> pre-congestion level for traffic from each PCN-ingress-node; if the=20
> level rises then it blocks new flows on that ingress-egress-aggregate.=20
> However, it=92s possible that an ingress-egress-aggregate carries no=20
> traffic, and so the PCN-egress-node can=92t make an admission decision=20
> using the usual method described earlier.
>
> One approach is to be =93optimistic=94 and simply admit the new flow.=20
> However it=92s possible to envisage a scenario where the traffic levels=
=20
> on other ingress-egress-aggregates are already so high that they=92re=20
> blocking new PCN-flows and admitting a new flow onto this 'empty'=20
> ingress-egress-aggregate would add extra traffic onto the link that=92s=
=20
> already pre-congested =96 which may =91tip the balance=92 so that PCN=92=
s flow=20
> termination mechanism is activated or some packets are dropped. This=20
> risk could be lessened by configuring on each link sufficient =91safety=
=20
> margin=92 above the PCN-lower-rate.
>
> An alternative approach is to make PCN a more proactive mechanism. The=20
> PCN-ingress-node explicitly determines, before admitting the=20
> prospective new flow, whether the ingress-egress-aggregate can support=20
> it. This can be seen as a =93pessimistic=94 approach, in contrast to th=
e=20
> =93optimism=94 of the approach above. It involves probing: a=20
> PCN-ingress-node generates and sends probe packets in order to test=20
> the pre-congestion level that the flow would experience. A probe=20
> packet is just a dummy data packet, generated by the PCN-ingress-node=20
> and addressed to the PCN-egress-node. A downside of probing is that it=20
> adds delay to the admission control process. Also note that in the=20
> scenario described in the previous paragraph (where traffic levels on=20
> other ingress-egress-aggregates is already very high), the probe=20
> packets may also =91tip the balance=92. However, the risk should be=20
> reduced because it should be possible to send probe packets for a=20
> shorter time and at a lower rate than a typical data flow.
>
> The situation is more complicated if there is multipath routing (ECMP)=20
> in the PCN-domain. It is then possible for some paths to be=20
> pre-congested whilst other paths within the same=20
> ingress-egress-aggregate aren't pre-congested.
>
> One approach essentially ignores ECMP: as usual, admit or block a new=20
> flow depending on the "measurements of PCN-traffic" on the=20
> ingress-egress-aggregate. This is rather similar to the =93optimistic=94=
=20
> approach above.
>
> An alternative (=93pessimistic=94 or =93proactive=94) approach is to pr=
obe the=20
> ECMP path. The PCN-ingress-node generates and sends probe packets=20
> (dummy data) that follow the specific ECMP path that the new flow=20
> would do, in order to test the pre-congestion level along it. An ECMP=20
> algorithm typically examines: the source and destination IP addresses=20
> and port numbers, the protocol ID and the DSCP. Hence these fields=20
> must have the same values in the probe packets as the future data=20
> packets would have. On the other hand, the PCN-egress-node needs to=20
> consume the probe packets to ensure that they don=92t travel beyond the=
=20
> PCN-domain (eg they might confuse the destination end node). Hence=20
> somehow the PCN-egress-node has to be able to disambiguate a probe=20
> packet from a data packet, via the characteristic setting of=20
> particular bit(s) in the packet=92s header or body =96 but these bit(s)=
=20
> mustn=92t be used by the PCN-node=92s ECMP algorithm.
>
> The probing functions are:
>
> o Make decision that probing is needed. As described above, this is=20
> when the ingress-egress-aggregate or the ECMP path carries no=20
> PCN-traffic. An alternative is always to probe, ie probe before=20
> admitting every PCN-flow.
>
> o (if required) Communicate the request that probing is needed =96 the=20
> PCN-egress-node signals to the PCN-ingress-node that probing is needed
>
> o Generate probe traffic - the PCN-ingress-node generates the probe=20
> traffic. The appropriate number (or rate) of probe packets will depend=20
> on the PCN-marking algorithm; for example an excess-rate-marking=20
> algorithm generates fewer PCN-marks than a threshold-marking=20
> algorithm, and so will need more probe packets.
>
> o Forward probe packets - as far as PCN-interior-nodes are concerned,=20
> probe packets must be handled the same as (ordinary data) PCN-packets,=20
> in terms of routing, scheduling and PCN-marking.
>
> o Consume probe packets - the PCN-egress-node consumes probe packets=20
> to ensure that they don't travel beyond the PCN-domain.
>
> ****
>
> Incidentally, I have edited the draft to include all the comments=20
> /discussion that there=92s been on the list since Vancouver. I=92ll add=
=20
> the above probing section [unless there are cries of unhappiness]. I=20
> also have some comments on paper from bob [will summarise to list=20
> where > typos etc]. So will send revised version out next week or end=20
> of this week.
>
> Best wishes
>
> phil
>
> -----------------------------------------------------------------------=
-
>
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www1.ietf.org/mailman/listinfo/pcn
>  =20

--=20
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:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn



_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn