Re: [mpls-tp] draft-boutros-mpls-tp-performance

["Thomas D. Nadeau" <[e-mail]>]

    Stewart,

    Why have you guys decided to invent a new protocol for performance
measurements versus using what is defined in RFC4656 (IPPM) and perhaps
re-encapsulating it for MPLS-TP purposes?

    --Tom



On 4/5/10 5:08 AM, "Stewart Bryant" <[e-mail]> wrote:

> Vishwas
> 
> Thank you for reviewing draft-boutros-mpls-tp-performance
> 
>  http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay-00 is a more
> robust protocol for measuring loss/delay and is the draft that I would
> prefer to move forward with.
> 
> - Stewart
> 
> 
> Vishwas Manral wrote:
>> Hi,
>> 
>> I noticed some interesting things in the performance monitoring draft.
>> The most interesting thing is point 4 I have noted.
>> 
>> 1. The draft may be trying to measure packet loss but it assumes the
>> performance messages cannot be lost. This seems like a very
>> interesting assmption.
>> 
>> 2. On the same lines if we assume the above not true, we may need to
>> define retransmits from senders and no/ ACK NACK retransmits.
>> 
>> 3. We also need to define how to identify duplicate messages and how
>> duplicate packets are to be treated.
>> 
>> 4. I also notice to measure packet loss we use the sequence number in
>> the packets themselves:
>> 
>> To measure packet loss I guess the receiver looks at the gaps in the
>> sequence numbers. However there are basic issues with this.
>> 
>> Sender sends packet 1 to 100. Receiver receives packet 1 to 80.
>> Receiver does not know 100 packets are going to be sent, so it says
>> packet loss is 0 even though there are 20 packets that are lost.
>> 
>> 5. I assume it would be good to state that the sequence number of the
>> first packet is 1. Also if there are wrap arounds what needs to be
>> done. In my view we should use 64 bit values for sequence numbers, it
>> is like a packet counter.
>> 
>> Thanks,
>> Vishwas
>> 
>>   
>