Re: [xrblock] (Bursts and Gaps) Open issue 1: Combing loss/discard

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Tue, 20 December 2011 18:34 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 20 Dec 2011 10:34:39 -0800
Message-ID: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C05FEE782@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <13833668.11791324352193658.JavaMail.root@ent12>
Thread-Topic: [xrblock] (Bursts and Gaps) Open issue 1: Combing loss/discard
Thread-Index: Acy+yJp/iR3XzpjZQQCfSERpftrN9AAfNXjA
References: <13833668.11791324352193658.JavaMail.root@ent12>
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: zhangyx@sttri.com.cn, xrblock <xrblock@ietf.org>
Subject: Re: [xrblock] (Bursts and Gaps) Open issue 1: Combing loss/discard
Precedence: list

(as an individual)

Proposal 3 sounds reasonable to me, and it addresses my concerns.

Cheers,
Charles

> -----Original Message-----
> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of zhangyx@sttri.com.cn
> Sent: Monday, December 19, 2011 7:37 PM
> To: xrblock
> Subject: [xrblock] (Bursts and Gaps) Open issue 1: Combing loss/discard
> 
> Following what we discussed in Taipei meeting regarding Bursts and gaps, we have agreed two things:
> a. Most measurement results in burst gap discard and burst gap loss drafts are redundant.
> b. Combine loss/discards is more useful to assess QoE, in some case, we only need to report burst gap
> loss.
> Therefore  there are  two proposals available on the list:
> http://www.ietf.org/mail-archive/web/xrblock/current/msg00113.html
> <https://imail.huawei.com/OWA/redir.aspx?C=9d17722dab3041e384ba029d0885948b&URL=http%3a%2f%2fwww.ietf.
> org%2fmail-archive%2fweb%2fxrblock%2fcurrent%2fmsg00113.html>
> 
> Proposal 1:  Combine burst gap discard draft and burst gap loss draft into a single burst-gap-loss-
> discard draft.
> Proposal 2:  keep burst gap loss draft as it does, replace burst gap discard draft with a new combined
> burst-gap-loss-discard draft.
> However proposal 2 will cause a lot of redundance. That is to say  combined burst-gap-loss-discard
> draft carry all the same measurement results
> reported in the burst gap draft.
> 
> On the other hand, burst-gap-loss-discard draft in both proposals put both discard related metric and
> loss related discard into the same metric block,
> this conflict with the rule described in draft-ietf-avtcore-monarch:
> "
> contain a single metric or a small number of metrics relevant to a single parameter
> "
> In order to reduce the reduancy in burst gap discard draft and burst gap loss draft, we propose as
> follows:
> Proposal3:  remove all the redundant data of burst gap discard draft which appears in the burst gap
> loss draft.
> Allocate one bit in the burst gap draft to indicate if combine loss/discard report is needed.
> 
> In this case, when we need to report both burst gap loss and burst gap discard, we can set indication
> bit in the burst gap loss metic block into 1, and carry burst gap loss and redundancy reduced burst
> gap discard in the same compound packet, if redundancy reduced burst gap discard is not sent with
> burst gap loss, then the receiver should discard burst gap loss with indication bit set to 1.
> When we only need to report burst gap loss, we can set indication bit in the burst gap loss metric
> block into 0, then receiver will not discard burst gap loss metric block when burst gap discard is not
> recieved.
> 
> This proposal has minor difference with our proposal discussed in the meeting. We believe the
> propsoal3 can address this open issue perfectly.
> Let us know what do you think of it?
> 
> Regards!
> Sunshine
> Shanghai Research Institute of China Telecom
>

[xrblock] (Bursts and Gaps) Open issue 1: Combing… zhangyx
Re: [xrblock] (Bursts and Gaps) Open issue 1: Com… Charles Eckel (eckelcu)
Re: [xrblock] (Bursts and Gaps) Open issue 1: Com… Qin Wu