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

From: Vishwas Manral <[email-masked]>
Date: Sun, 4 Apr 2010 20:32:39 -0700

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

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 4 Apr 2010 20:34:50 -0700

Resending as DWards Cisco address was used.

Thanks,
Vishwas

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 05 Apr 2010 10:08:20 +0100

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

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 05 Apr 2010 07:56:47 -0400

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 05 Apr 2010 18:09:24 +0100

Tom

Remember its 
http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay-00 not 
draft-boutros-mpls-tp-performance that you need to look at

Why not RFC4656

1) We did not think that we could get 4656 efficiently implemented in h/w

2) We assumed that we would not have TCP available as the control 
channel, so we would have needed to create new control channel

3) We need both one way and two way, including two way without GPS 
clocks at the remote

- Stewart

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 5 Apr 2010 10:17:56 -0700

Hi Stewart,

I read the draft and it looked considerably better than the other one
on the first skim of the draft.

I will send across comments on the new draft.

Thanks,
Vishwas

On Mon, Apr 5, 2010 at 10:09 AM, Stewart Bryant <[email-masked]> wrote:
> Tom
>
> Remember its http://tools.ietf.org/html/draft-frost-mpls-tp-loss-delay-00
> not draft-boutros-mpls-tp-performance that you need to look at
>
> Why not RFC4656
>
> 2) We assumed that we would not have TCP available as the control channel,
> so we would have needed to create new control channel
>
> 3) We need both one way and two way, including two way without GPS clocks at
> the remote
>
> - Stewart
>
>
>
> Thomas D. Nadeau wrote:
>>
>>    Stewart,
>>

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 06 Apr 2010 14:42:53 +0200

Hello Tom,

> re-encapsulating it for MPLS-TP purposes?

This protocol already exists for a long time.
So it is *not* an invention but re-use.

Regards, Huub.

> On 4/5/10 5:08 AM, "Stewart Bryant"<[email-masked]>  wrote:
>
>> Vishwas
>>

-- 
================================================================
Always remember that you are unique...just like everyone else...