Subject: [nvo3] bandwidth requirements of the tenants in draft-narten-nvo3-overlay-problem-statement-02.txt

From: Selvam Ramanathan <[email-masked]>
Date: Tue, 10 Jul 2012 19:40:05 -0400

Hi ,

Should the overlay-problem-statement-02 also talk about the
issues arising out of the bandwidth requirements of the tenants ?

Regards,
Selvam

---

From: Truman Boyes <[email-masked]>
Date: Tue, 10 Jul 2012 22:01:56 -0400

What are these issues relating to bandwidth that you are referring to that
are specific to overlays or to the lack of overlays?

Regards,
Truman

On Tue, Jul 10, 2012 at 7:40 PM, Selvam Ramanathan <
[email-masked]> wrote:

> Hi , ****
>
> ** **
>
> Should the overlay-problem-statement-02 also talk about the ****
>
> issues arising out of the bandwidth requirements of the tenants ? ****
>
> ** **
>
> Regards, ****
>
> Selvam ****
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Selvam Ramanathan <[email-masked]>
Date: Wed, 11 Jul 2012 19:55:28 -0400

Hi Truman,

Lets Take a case where Tenant A and Tenant B are configured.
Since  Tenant A and Tenant B are using the same physical network over the multiple overlay network ,
How do we make Sure Tenant A gets the bandwidth he needs & Tenant B is not overwhelming the
Network .

Let's take a case where  Tenant A might be running Video Streaming Servers on his VM/Endpoint &
>From Tenant A's  perspective its required for the Virtual DC  to guarantee his bandwidth requirements.

Regards,
Selvam

From: Truman Boyes [mailto:[email-masked]]
Sent: Tuesday, July 10, 2012 7:02 PM
To: Selvam Ramanathan
Cc: [email-masked]
Subject: Re: [nvo3] bandwidth requirements of the tenants in draft-narten-nvo3-overlay-problem-statement-02.txt

What are these issues relating to bandwidth that you are referring to that are specific to overlays or to the lack of overlays?

Regards,
Truman

On Tue, Jul 10, 2012 at 7:40 PM, Selvam Ramanathan <[email-masked]<mailto:[email-masked]>> wrote:
Hi ,

Regards,
Selvam

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Truman Boyes <[email-masked]>
Date: Thu, 12 Jul 2012 00:01:04 -0400

Hi Selvam,

Yes I agree this does need to be discussed. There could be a couple methods
in achieving this:

   - The virtual bridge on the hypervisor of the NVE can handle the
   rate-limiting ingress or egress from the TES on the VAP.
   - If the encapsulation is IP between the NVE, we could ensure that
   appropriate DSCP/ToS markings are copied into the IP header based on
   configured mappings of tenant QoS priority. This way standard physical
   network devices can also appropriately provide the intended per hop
   behavior.
   - The IP ToS or DSCP values from packets generated from TES could be
   simply copied into encapsulation IP header; if a corresponding VAP or
   policy existed on the VNI.

Just some quick thoughts on this at midnight ...

Kind regards,
Truman

On Wed, Jul 11, 2012 at 7:55 PM, Selvam Ramanathan <
[email-masked]> wrote:

> Hi Truman, ****
>
> ** **
>
> Lets Take a case where Tenant A and Tenant B are configured. ****
>
> Since  Tenant A and Tenant B are using the same physical network over the
> multiple overlay network , ****
>
> How do we make Sure Tenant A gets the bandwidth he needs & Tenant B is not
> overwhelming the ****
>
> Network . ****
>
> ** **
>
> Let’s take a case where  Tenant A might be running Video Streaming Servers
> on his VM/Endpoint & ****
>
> From Tenant A’s  perspective its required for the Virtual DC  to guarantee
> his bandwidth requirements.  ****
>
> ** **
>
> Regards, ****
>
> Selvam ****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Truman Boyes [mailto:[email-masked]]
> *Sent:* Tuesday, July 10, 2012 7:02 PM
> *To:* Selvam Ramanathan
> *Cc:* [email-masked]
> *Subject:* Re: [nvo3] bandwidth requirements of the tenants in
> draft-narten-nvo3-overlay-problem-statement-02.txt****
>
> ** **
>
> are specific to overlays or to the lack of overlays? ****
>
> ** **
>
> Regards,****
>
> Truman****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi , ****
>
>  ****
>
>  ****
> https://www.ietf.org/mailman/listinfo/nvo3****
>
> ** **
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 08:04:53 +0100

Truman,

>    policy existed on the VNI.

Diffserv alone cannot ensure sharing between two competing streams
of the same class of traffic that happen to occur in two different tunnels.
You would definitely need admission control of some kind at *all* tunnel
ingresses, as far as I can see. Whether that scales is another question.

FYI, diffserv handling in tunnels is documented in RFC 2983.

    Brian Carpenter

---

From: Truman Boyes <[email-masked]>
Date: Thu, 12 Jul 2012 10:43:27 -0400

Brian, I agree that diffserv alone would not address the condition if more granular QoS/CoS is required. If we think of NVE as PE a device then I believe we have the necessary components. 

Ingress classification on the VAP as well as the potential to classify on the VNIF will handle mapping from header details to appropriate queue.

Marking of outer tunnel header as we do today with exp bits or gre ip header will ensure end to end PHB. 

The missing link is how to handle the condition you describe; two streams, same traffic class, different tunnels. Maybe the provider should provide distinction of queue/class if there is an expectation of behavior differences. Or we will need to use the second VNID (briefly described in the framework doc) as a means to provide greater differentiation.

Building a form of call admission control  for tenant streams to the network is looking for a world of hurt. IntServ can be our testament to this truth. ;)

Kind regards,
Truman Boyes

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 17:39:38 +0100

> Building a form of call admission control  for tenant streams to the network is looking for a world of hurt. IntServ can be our testament to this truth. ;)

To be clear, in the diffserv context, admission control does not imply state per
stream; it really implies a token bucket per diffserv class and per tunnel. If
you limit things to a handful of diffserv classes, that ought to scale.

Alternatively, provide too much bandwidth. That may well be cheaper.

   Brian