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

From: Vishwas Manral <[email-masked]>
Date: Mon, 3 Jun 2013 08:56:47 -0700

Hi Yoav,

Do we see a conclusion on the QoS requirement and if we want to include it
as part of the ADVPN solution or keep it seperate?

Thanks,
Vishwas

On Thu, May 2, 2013 at 1:11 PM, Yoav Nir <[email-masked]> wrote:

>  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]> wrote:
>
>
>  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
>
>
>
>
> Email secured by Check Point
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>