Subject: RE: Internet Draft Submission: Orchestrally Conducted Traffic

From: [email-masked]
Date: Wed, 15 Mar 2000 19:26:20 -0000

CNLS = Success?  I am not sure the CNLS facet is is the only real 'success'
criteria.   If we are honest, IP has been about 30 years in gestation, but
the real traffic take-off (=success??) of the Internet really only came
about because of some other protocols developed by Tim Berners-Lee which
defined the WWW (and, of course, the impact of Moore's law on silicon).

A CNLS transfer mode is important, but then so is a CO one.

Here are two examples why:

1	In a true CNLS mode if N sites all send to single egress, then if
the end-system cannot handle the multiplexed streams (eg a human is on the
end say) then one has little choice but to drop the pkts.  Not good news if
they have passed an input UPC type function at each of the N sites (ie
valid/in-contract traffic), and this impacts congestion and network billing
issues.  Clearly we need some CAC-type function here.....at least wrt
ingress/egress, even if we don't reserve resources at all nodes along the
route.  But is this CO or CNLS?......looks something in the middle to me,
and indeed there is a wide range of grey between true CNLS and CO (see Radia
Perlman, Chapter 5 of 'Interconnections').

2	Anyone even cursorily familar with DiffServ knows it will not allow
QoS service differentiation for the majority of operational time (and
goodness knows how marketing people are going to sell this stuff).  Indeed,
DS only kicks in during congestion (maybe as a consequence of a network
failure).  Customers are very quickly going to work-out that an operator's
'bronze' service is effectively as good as the 'gold' service over the vast
majority of operational time......and the differentiator is not QoS per se
but more related to survivalbility.
Aside......if one wanted to force QoS differentiation over the vast majority
of operational time one would have to use dynamically changing (slowly) hard
BW partitions between each DS class to maintain a given user/unit-BW
density.  These hard BW partitions are CO trail objects (in trad L2
speak)......but it looks a horrble control problem, and it may be easier to
throw BW at the problem (at least in the core) so all we end up with is a
scheduling issue at access points.

A key concern here would be if all we could only ever do was to take
different customer VPN traffic and aggregate this into like DS classes, ie
one had lost sight of the VPN topology.  So now, on failure, an operator may
not be able to offer a solid perspective on overall VPN survivability.  A
further complication will arise when in one VPN (or even a work-group
partition of one VPN) Voice is seen as mission critical but in another VPN
(or partition) it is not.  We may get some interesting comments from
customers about this during periods of congestion (whatever their cause). 

So, whilst some VPN customers will be happy with mass aggreation and loss of
sight of topology others will not......and I suspect availability SLAs will
be a more important metric to many VPN customers that (up-state) QoS
metrics.  For the latter type of VPN customers we operators will probably
want to offer an overall 'effective BW topology' against a given
survivability index/SLA, and we would therefore let those type of VPN
customers use their own DS classifications as they saw fit....our primary
concern here would be to make sure the overall VPN survived.

Thanks, Neil

> -----Original Message-----
> From:	Loa Andersson [SMTP:[email-masked]]
> Sent:	Wednesday, March 15, 2000 2:53 PM
> To:	Hummel Heinrich
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: Internet Draft Submission: Orchestrally Conducted
> Traffic
> 
> Heinrich,
> 
> there is something that worries me very much about this. From the 
> abstract:
> 
> "This draft proposes to engineer traffic such that we can speak of  an
> Orchestrally  Conducted  Traffic  (OCT): Any traffic stream (given by
> its source and destination nodes and by a  priority  class)  may  use
> several  differently  routed  LSPs.   Each,  traffic  stream  ingress
> reports,  periodically,  the  currently  measured  traffic  load  (in
> bitrate)  to  a  common  TE  Conductor (TEC) who evaluates them as to
> guess what traffic load change might  occur  in  the  immediate  time
> ahead.  Accordingly  the  TEC   computes well synchronized likelihood
> values by which to take which route/LSP. These values  will  be  such
> that  any traffic stream will be served as good as possible, as often
> as possible, while equally ranked traffic streams are  treated  fair,
> higher  ranked  streams  are prioritized  and  the network thruput is
> maximized. The TEC sends the  likelihood  values  to  the  respective
> ingress  node,  who  will   distribute  the  received  packets of the
> traffic stream to the pertaining LSPs accordingly."
> 
> I might misread this, but the IP paradigm has been connection less from
> the start, and very much of the success of IP is because of its of this
> connection less nature. I do see that we "violate" this little bit by
> some of the proposals that has been discussed in the mpls and te 
> working groups - for what I believe is good reasons. However we should
> take extreme care of keeping the connection less nature of IP
> networks.
> 
> The Orchestrated Conducted Traffic draft seems to take an extreme 
> connection oriented approach. We should take care not throw the
> baby, bath tub and bath water out at the same time.
> 
> /Loa
> 
> Hummel Heinrich wrote:
> > 
> > Hi all,
> > 
> > I emailed draft-hummel-te-oct-01.txt to [email-masked].
> > I also applied for a time-slot in the TE-WG for presenting this traffic
> > balancing concept in Adelaide.
> > I appreciate any comment on this topic.
> > 
> > Regards
> > 
> > Heinrich Hummel
> > Siemens AG
> > [email-masked]
> 
> -- 
> 
> Loa Andersson
> Director Routing Architecture Lab, EMEA
> St Eriksgatan 115A, PO Box 6701
> 113 85 Stockholm, Sweden
> phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> e-mail: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 15 Mar 2000 15:18:29 -0500

> concern here would be to make sure the overall VPN survived.

Was this a religious commentary or was it somehow related to the draft
being discussed?

Curtis