Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

From: Toby Mao <[email-masked]>
Date: Thu, 2 May 2013 23:02:48 +0800

On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <[email-masked]>wrote:

> These requirements might be useful to add in the next draft, but they need
> to be refined.
>
> On Apr 26, 2013, at 8:10 PM, Toby Mao <[email-masked]> wrote:
>
> > The ADVPN solution SHOULD be able to implement Quality of Service (QoS)
> to regulate the traffic in the ADVPN topology.
>
> Why is this statement needed? Do you see situations where an ADVPN
> solution would be *prevented* from implementing some sort of QoS because it
> was an ADVPN?
>

 [Toby]: There is no situation that ADVPN solution could be prevented from
implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing
network bandwidth, meeting the application latency requirement. Especially
in the Hub, for each spoke, the Qos policy should be implemented
individually , because different spoke has different link speed and data
processing capability. Thus, in the ADVPN solution, the small spoke can not
be overrun by hub by sending too much traffic, also the spoke which has
large bandwidth cannot hog the hub's resources and starve other spokes. In
addition, a unique Qos policy for each spoke in the hub could be cumbersome
for administrator, some improvement could be implemented, such as the
spokes with the same bandwidth can belong to the same group, the Qos policy
can be implemented on a basis of group.

>
> > ADVPN peer SHOULD NOT send excessive traffic to the other members of
> ADVPN.
>
> How would you define "excessive"? Where would that measurement be done?

[Toby]  The traffic to the ADVPN peer exceeding the actual peer bandwidth
can be defined as "excessive". To solve this problem, the other ADVPN peer
should apply Qos policy for this ADVPN peer.

> The traffic for each ADVPN peer CAN be measured individually for shaping
> and policing.
>
> Why is this statement needed? Do you see situations where an ADVPN
> solution would be *prevented* from measuring individually?

[Toby]  The reason is explained in the first answer.

> --Paul Hoffman

---

From: Toby Mao <[email-masked]>
Date: Thu, 2 May 2013 23:08:14 +0800

Hi Vishwas:

I agree with you.  The Qos implementation in ADVPN is not different with
traditional IPsec VPN at all, and this requirement is to specify Qos policy
for each ADVPN peer in the hub.

Best regards,

Toby

On Mon, Apr 29, 2013 at 12:00 PM, Vishwas Manral <[email-masked]>wrote:

> Hi Toby,
>
> I absolutely understand the rational of where you are coming from. I agree
> with questions raised by Paul - we need to be characterize the requirement
> a bit further.
>
> I know QoS is important especially if there is an overload of traffic with
> multiple different use cases. However do we see it any different from any
> other VPN we currently run? I agree policing, shaping, marking etc are
> mechanisms to implement QoS and are important. May be the requirement would
> be to specify the capability to do fine grained QoS on a per peer basis on
> the Hub. Sounds reasonable?
>
> Thanks,
> Vishwas
>
>
> On Sat, Apr 27, 2013 at 8:27 PM, Paul Hoffman <[email-masked]>wrote:
>
>> These requirements might be useful to add in the next draft, but they
>> need to be refined.
>>
>> > The traffic for each ADVPN peer CAN be measured individually for
>> shaping and policing.
>>
>> _______________________________________________
>> IPsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 May 2013 20:11:42 +0000

Hi Toby.

Let's see if I understand the issue. I'll describe this with an example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS policy. So if A, B, and C are simultaneously sending traffic to E through Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP ACKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to bypass Z. Initially A had no IPsec policy about E. There's no reason to think it had a QoS policy about E, and the same is true in the other direction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and have the QoS targets miss.

So whereas before ADVPN the center gateway could be counted on to handle the QoS (because everything goes through it), as soon as you add ADVPN, that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of AD-VPN, but I want to make sure that we understand the issue.

Yoav

On May 2, 2013, at 6:02 PM, Toby Mao <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
These requirements might be useful to add in the next draft, but they need to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <[email-masked]<mailto:[email-masked]>> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution would be *prevented* from implementing some sort of QoS because it was an ADVPN?

 [Toby]: There is no situation that ADVPN solution could be prevented from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing network bandwidth, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should be implemented individually , because different spoke has different link speed and data processing capability. Thus, in the ADVPN solution, the small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cannot hog the hub's resources and starve other spokes. In addition, a unique Qos policy for each spoke in the hub could be cumbersome for administrator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, the Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVPN.

[Toby]  The traffic to the ADVPN peer exceeding the actual peer bandwidth can be defined as "excessive". To solve this problem, the other ADVPN peer should apply Qos policy for this ADVPN peer.

> The traffic for each ADVPN peer CAN be measured individually for shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution would be *prevented* from measuring individually?

--Paul Hoffman

Email secured by Check Point

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

---

From: Toby Mao <[email-masked]>
Date: Sun, 5 May 2013 23:49:15 +0800

Hi Yoav.

         The QoS implementations in ADVPN are :

1.        In the star topology,  the QoS policy is implemented individually
for each spoke in the hub, all the traffic through the Hub can be regulated
by QoS policy in the hub.

2.       In the full mesh topology,  when the two spokes establish the
direct connection, each spoke should also have the QoS policy for each
other. The QoS policy can be obtained from the Hub, or other control device
,  which has the individual QoS policy for each spoke.

I think your understanding is the same as the QoS implementation in the
full mesh topology.

Toby

On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <[email-masked]> wrote:

>  Suppose we have satellite gateways A, B, C, D, and E. A through D each
> have a bandwidth of 10 Mb/s, while E has 20 Mb/s.
>
>  The center gateway, Z, has plenty of bandwidth and the appropriate QoS
> policy. So if A, B, and C are simultaneously sending traffic to E through
> Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP
> ACKs) to make sure the QoS goals are met.
>
>  Now add ADVPN to the mix. A and E discover each other, and are able to
> bypass Z. Initially A had no IPsec policy about E. There's no reason to
> think it had a QoS policy about E, and the same is true in the other
> direction. Unless the QoS policy from Z somehow gets transmitted to the
> satellites, they may reach congestion and have the QoS targets miss.
>
>  So whereas before ADVPN the center gateway could be counted on to handle
> the QoS (because everything goes through it), as soon as you add ADVPN,
> that policy has to be enforced on the spokes, or not at all.
>
>  I'm not sure whether we can or should solve this issue as part of
> AD-VPN, but I want to make sure that we understand the issue.
>
>  Yoav
>
>  On May 2, 2013, at 6:02 PM, Toby Mao <[email-masked]> wrote:
>
>
>   [Toby]: There is no situation that ADVPN solution could be prevented
> from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 6 May 2013 16:30:50 +0000

Hi Toby,

When you say QoS policy, could you elaborate what it really means? I mean what kind of information does it need to have or exchanged?

-- Praveen

From: Toby Mao <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 5, 2013 8:49 AM
To: Yoav Nir <[email-masked]<mailto:[email-masked]>>
Cc: IPsecme WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Paul Hoffman <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

1.        In the star topology,  the QoS policy is implemented individually for each spoke in the hub, all the traffic through the Hub can be regulated by QoS policy in the hub.

2.       In the full mesh topology,  when the two spokes establish the direct connection, each spoke should also have the QoS policy for each other. The QoS policy can be obtained from the Hub, or other control device ,  which has the individual QoS policy for each spoke.

I think your understanding is the same as the QoS implementation in the full mesh topology.

Toby

On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
Hi Toby.

Yoav

--Paul Hoffman