Hello Mach,
so for delay measurement you use the color flag to mark a single packet,
which helps the receiver to pick the right packet? And repeat this every
time period T ?
...000100000010000001000...
One question I still have is: why is the measurement done in the NVE header?
The outer header is IP/IPv6, so couldn't we use the coloring for the IP/IPv6
header, assuming this is defined?
Thanks & Regards,
Marc
On Wed, 12 Nov 2014 09:34:52 +0000, Mach Chen wrote:
> Hi Tom,
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:[email protected]]
>> Sent: Wednesday, November 12, 2014 5:06 PM
>> To: Mach Chen
>> Cc: Greg Mirsky; Haoweiguo; [email protected]; Larry Kreeger (kreeger)
>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
>>
>> On Wed, Nov 12, 2014 at 12:55 AM, Mach Chen <[email protected]>
>> wrote:
>>> Hi Greg and all,
>>>
>>>
>>>
>>> Single bit is not sufficient if someone wants to perform loss and
>>> delay measurement simultaneously, then two bits needed.
>>>
>> Is that necessary? Can they share the same time quantum (as well as other
>> metrics maybe to be added later)? In all the protocols mentioned, the
>> reserved
>> bits are a somewhat precious resource.
>
> Yes, it's necessary if there is ECMP.
>
> Given one bit is used for both loss and delay measurement, for loss
> measurement, it periodically set and clear the marking bit, a flow is
> divided into consecutive blocks, and then the counting and calculating are
> based on each block. This is fine for loss measurement.
>
> For delay measurement, it has to make sure the timestamps (collected at
> sender and receiver) are for the same packet. Presumably, the time when
> changing the marking bit is right time to get the timestamps. Since there
> is ECMP, the first packet of a block at the sender may probably different
> from the first packet at the receiver, thus it will get the mismatched
> timestamps to calculate the delay.
>
> Best regards,
> Mach
>>
>> Tom
>>
>>>
>>>
>>> Best regards,
>>>
>>> Mach
>>>
>>>
>>>
>>> From: nvo3 [mailto:[email protected]] On Behalf Of Greg Mirsky
>>> Sent: Wednesday, November 12, 2014 8:05 AM
>>> To: Haoweiguo
>>> Cc: [email protected]; Larry Kreeger (kreeger)
>>> Subject: Re: [nvo3] 答复: Comments on NVO3 data plane requirements for
>>> OAM
>>>
>>>
>>>
>>> Dear All,
>>> agree with Weiguo, single bit flag in fixed position would be
>>> sufficient and HW-friendly.
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Tue, Nov 11, 2014 at 3:51 PM, Haoweiguo <[email protected]>
>> wrote:
>>>
>>> Hi Larry,
>>>
>>> For marking purpose, i think one bit maybe OK, fixed fields in NVO3
>>> header is precious. I would like it is set in fixed field, rather than
>>> in option field. Because chipset normally can't process optional
>>> field, it is hard to realize in-band performance measurement if using
>>> optional
>> field for marking.
>>> For other real time congestion control function, maybe more bits are
>>> needed.
>>>
>>> Thanks
>>>
>>> weiguo
>>>
>>> ________________________________
>>>
>>> 发件人: Larry Kreeger (kreeger) [[email protected]]
>>> 发送时间: 2014年11月12日 4:33
>>> 收件人: Haoweiguo; Greg Mirsky
>>>
>>>
>>> 抄送: [email protected]
>>> 主题: Re: [nvo3] Comments on NVO3 data plane requirements for OAM
>>>
>>>
>>>
>>> Hi Weiguo,
>>>
>>>
>>>
>>> What do you envision this marking looking like? e.g. is it just a
>>> single flag bit, or large field with a counter or sequence number, or
>>> some kind of flow ID? If not a single flag, how large do you see the
>>> field
>> being?
>>>
>>>
>>>
>>> If it is more than a flag (and I assume it would be), and is not
>>> mandatory for all implementations, then it seems to fall into the
>>> category of optional extensions.
>>>
>>>
>>>
>>> Thanks, Larry
>>>
>>>
>>>
>>> From: Haoweiguo <[email protected]>
>>> Date: Tuesday, November 11, 2014 10:18 AM
>>> To: Greg Mirsky <[email protected]>
>>> Cc: "[email protected]" <[email protected]>
>>> Subject: [nvo3] 答复: Comments on NVO3 data plane requirements for OAM
>>>
>>>
>>>
>>> Hi Greg,
>>>
>>> I fully agree with you.
>>>
>>> The real time OAM is passive performance measurement methods. I would
>>> like
>>> NVO3 data encapsulation has a field for marking and not affect
>>> forwarding of packets, the marking field is only used for performance
>>> measurement. The
>>> NVO3 packet with this marking flag don't need to be sent to control
>>> plane, it is different from OAM(ping/Trace) packet processing.
>>>
>>> Thanks
>>>
>>> weiguo
>>>
>>> ________________________________
>>>
>>> 发件人: Greg Mirsky [[email protected]]
>>> 发送时间: 2014年11月12日 4:07
>>> 收件人: Haoweiguo
>>> 抄送: [email protected]
>>> 主题: Re: [nvo3] Comments on NVO3 data plane requirements for OAM
>>>
>>> Hi Weiguo,
>>>
>>> marking groups of packets that belong to the particular flow to
>>> facilitate measurement of some performance metric, whether loss or
>>> delay/delay variation, may be viewed as one of passive performance
>> measurement methods.
>>> But such marking should not alter, at least not significantly alter,
>>> treatment of data flow in the network. Because of that, I believe, OAM
>>> flag should not be used for marking as that will force punting marked
>>> packets from fast forwarding path to the control plane. But it might
>>> be good to have a field in NVO3 header that may be used for marking
>>> and not affect forwarding of packets if altered.
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Tue, Nov 11, 2014 at 12:34 AM, Haoweiguo <[email protected]>
>> wrote:
>>>
>>> Hi All,
>>>
>>> I maybe not clearly said in today’s NVO3 meeting, pls allow me to
>>> reiterate the OAM data plane requirements on the mail list.
>>>
>>> Currently NVO3 data plane encapsulation only includes one OAM flag, it
>>> is used for Ping/Trace similar applications. This kind of OAM
>>> application is initiated by operators for network connectivity
>>> verification, normally when network failure occurs. There is another
>>> OAM requirements of real time OAM or synthesizing OAM. It can be used for
>> packet loss detection in real time.
>>> When ingress NVE receives traffic from local TS, it gets packet
>>> statistics, and mark(coloring) the OAM flag relying on local policy
>>> when it performs
>>> NVO3 encapsulation. When egress NVEs receives the traffic, it
>>> decapsulates
>>> NVO3 encapsulation, and gets packet statistics with the real time OAM
>>> flag marking. By comparing the packet number of ingress NVE and the
>>> sum of all egress NVEs, packet loss can be deduced. This method can be
>>> applicable for both unicast and multicast traffic. Local policy on
>>> ingress NVE is configured by operators or automatically acquired from
>>> centralized orchestration.
>>>
>>> Thanks
>>>
>>> weiguo
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
