Re: [rohc] 答复: Re: Feedback formats

Klaus Warnke <klaus.warnke@acticom.de> Fri, 17 July 2009 09:44 UTC

Return-Path: <klaus.warnke@acticom.de>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289233A69A0 for <rohc@core3.amsl.com>; Fri, 17 Jul 2009 02:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exz6nncx7MR2 for <rohc@core3.amsl.com>; Fri, 17 Jul 2009 02:44:43 -0700 (PDT)
Received: from mail.acticom-networks.com (mail.acticom-networks.com [87.106.254.214]) by core3.amsl.com (Postfix) with ESMTP id 1BFE63A6E2E for <rohc@ietf.org>; Fri, 17 Jul 2009 02:44:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.acticom-networks.com (Postfix) with ESMTP id 4BB371C00435; Fri, 17 Jul 2009 11:45:08 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at acticom-networks.com
Received: from mail.acticom-networks.com ([127.0.0.1]) by localhost (mail.acticom-networks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HucEhRYZMFou; Fri, 17 Jul 2009 11:44:59 +0200 (CEST)
Received: from godfather.bln.acticom.de (mail.oosoft.net [212.99.204.33]) by mail.acticom-networks.com (Postfix) with ESMTP id 06E551C0042E; Fri, 17 Jul 2009 11:44:59 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by godfather.bln.acticom.de (Postfix) with ESMTP id 51783F3ADA; Fri, 17 Jul 2009 11:44:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at bln.acticom.de
Received: from godfather.bln.acticom.de ([127.0.0.1]) by localhost (godfather.bln.acticom.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0Rro+XjiAiE; Fri, 17 Jul 2009 11:44:55 +0200 (CEST)
Received: from [192.168.33.27] (tornado.bln.acticom.de [192.168.33.27]) by godfather.bln.acticom.de (Postfix) with ESMTP id 99B6FF3AD7; Fri, 17 Jul 2009 11:44:55 +0200 (CEST)
Message-ID: <4A604817.5070104@acticom.de>
Date: Fri, 17 Jul 2009 11:44:55 +0200
From: Klaus Warnke <klaus.warnke@acticom.de>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: cai.wei2@zte.com.cn
References: <OFCFA5F207.DD56A952-ON482575F6.0000E3DC-482575F6.00039C34@zte.com.cn>
In-Reply-To: <OFCFA5F207.DD56A952-ON482575F6.0000E3DC-482575F6.00039C34@zte.com.cn>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: rohc@ietf.org
Subject: Re: [rohc] 答复: Re: Feedback formats
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2009 09:44:44 -0000

Cai,
 > non mode transitions: should we send feedback with mode parameter?
No, I don't think so. Why?
If there is no mode transition in progress, there is no need to
send a mode parameter.  But if there is a need to send a feedback
option (clock resolution, for example) you  must use feedback-2
and then the mode parameter must set correct.

 > if YES, which case we could use feedback-1 in profile RTP?
Where do you see a problem to use feedback-1 together with the
RTP profile?
If the decompressor ACKs an context update, a feedback-1 packet
is ok.  This could be done with a feedback-2 packet too, but why
sending larger packets than needed?  The only exception I know is
using RTP profile in optimistic mode with sparse ACK (5.7.6.) and
sending no ACK.  If you sending no ACK, no feedback-1 is
needed, because NACK is always a feedback-2 packet. But for
reliable mode you need feedback-1.

br
Klaus Warnke

cai.wei2@zte.com.cn wrote:
>
> Klaus, Calle,
>
> Thank you for the detailed interpretation and sorry for joining the 
> discussion so late.
>
> I think there is no doubt that when mode transitions, any feedback 
> should be sent with mode transition parameter;
>
> i.e., use feedback-2
>
> the question is that the feedback logic of non mode transitions: 
> should we send feedback with mode parameter?
>
> if YES, which case we could use feedback-1 in profile RTP?
>
> Thanks
> 	
> *caiwei 167981*
> LTE Development Department | LTE开发部
> 	*Product Marketing System *
> *产品市场体系*
> D3-06, ZTE Corp., No.10 South Tangyan Rd.,
> Hi-tech Industrial Development Zone, Xi'an,
> P.R.China, 710065
> Tel:+86-29-88724112, 15801916689
> Email:167981@zte.com.cn
>
>
>
>
>
>
> *Klaus Warnke <klaus.warnke@acticom.de>*
>
> 2009-07-16 22:15
>
> 	
> 收件人
> 	Carl Knutsson <carl.knutsson@effnet.com>, cai.wei2@zte.com.cn
> 抄送
> 	rohc@ietf.org
> 主题
> 	Re: [rohc] Feedback formats
>
>
>
> 	
>
>
>
>
>
> Calle, Cai,
>
> yes, I'm wrong.
> "short cut" means, there is no handshake procedure needed, but using
> feedback-1 was too short.
>
> br
> Klaus
>
> Carl Knutsson wrote:
> > Klaus, Cai,
> >
> > Using the "short cut" as Klaus describes below is not really allowed in
> > RFC3095. Section 5.6.1 is quite clear that all feedback during a mode
> > transition must carry a CRC option. The mode parameter must also be set
> > to O to transfer from U-mode to O-mode. FEEDBACK-1 doesn't have a mode
> > field and cannot carry feedback options.
> >
> > Klaus, I guess you refer to the last paragraph of section 5.6.2. It
> > should not be interpreted by its own. I agree that the wording is a bit
> > unfortunate, but I can still not see how it can be interpret it this
> > way. FEEDBACK-1 cannot be used for mode transfer between U-mode and
> > O-mode. The compressor simply don't have the information to which mode
> > to transfer to.
> >
> >
> > Cheers,
> >
> > /Calle
> >
> >
> > Klaus Warnke wrote:
> >  
> >> Hello cai,
> >>
> >> I'm not completely sure what your mean.
> >>
> >> First, there is a "short cut" to switch from U to O
> >> mode (5.6.2.). In this case, a feedback-1 is sufficient, because
> >> the receiving of any feedback shows to compressor that a feedback
> >> channel is available and this is the precondition for bidirectional
> >> optimistic mode.
> >>
> >> Ideally the mode transition should be profile independent. But for the
> >> IR/IR-DYN packet it isn't due to a design flaw. Only the dynamic chain
> >> of the RTP Header contains the 'M' (5.7.7.6.) flag to transmit a
> >> compression mode. For the other profiles you must use a extension-3.
> >>
> >> Hope that helps.
> >>
> >> If not, could you please explain the problem more detailed?
> >>
> >> br
> >> Klaus Warnke
> >>
> >>
> >> cai.wei2@zte.com.cn wrote:
> >>    
> >>> RFC 3095 describes that when mode transitions, any feedback should be
> >>> sent with mode transition parameter;
> >>>
> >>> at the same time, the feedback logic of decompressor in U/O/R mode
> >>> also send feedback with mode parameter.
> >>>
> >>> there is a doubt that which case we could use feedback-1 in 
> profile RTP?
> >>>
> >>> Thanks
> >>>                  
> >>> *caiwei 167981*
> >>> LTE Development Department | LTE¿ª·¢²¿
> >>>                  *Product Marketing System *
> >>> *²úÆ·Êг¡Ìåϵ*
> >>> D3-06, ZTE Corp., No.10 South Tangyan Rd.,
> >>> Hi-tech Industrial Development Zone, Xi'an,
> >>> P.R.China, 710065
> >>> Tel:+86-29-88724112, 15801916689
> >>> Email:167981@zte.com.cn
> >>>
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------
> >>> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated to 
> maintain secrecy and are not permitted to disclose the contents of 
> this communication to others.
> >>> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed. If you have received this email in error please notify 
> the originator of the message. Any views expressed in this message are 
> those of the individual sender.
> >>> This message has been scanned for viruses and Spam by ZTE 
> Anti-Spam system.
> >>>  
> >>> 
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Rohc mailing list
> >>> Rohc@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rohc
> >>>  
> >>>      
> >> _______________________________________________
> >> Rohc mailing list
> >> Rohc@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rohc
> >>    
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>   


-- 
Klaus Warnke                klaus.warnke@acticom.de
http://www.acticom.de
Tel +49-30-4303.2510        Fax +49-30-4303.2519
* --------------------------------------------------------- *
acticom GmbH
Am Borsigturm 42, 13507 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766
* --------------------------------------------------------- *
This email and the information it contains may be
privileged and/or confidential. It is for the intended
addressee(s) only. The unauthorised use, disclosure or
copying of this email, or any information contained,
is prohibited. If you are not an intended recipient,
please notify the sender immediately and delete this email.