Re: [Fecframe] Pete Resnick's Discuss on draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)

Pete Resnick <presnick@qualcomm.com> Fri, 24 February 2012 15:01 UTC

Return-Path: <presnick@qualcomm.com>
X-Original-To: fecframe@ietfa.amsl.com
Delivered-To: fecframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B4521F843E for <fecframe@ietfa.amsl.com>; Fri, 24 Feb 2012 07:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.573
X-Spam-Level:
X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6dX9-q9a92E for <fecframe@ietfa.amsl.com>; Fri, 24 Feb 2012 07:01:35 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 212ED21F86F6 for <fecframe@ietf.org>; Fri, 24 Feb 2012 07:01:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1330095695; x=1361631695; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F47A64A.4020206@qualcomm.com>|Date:=20Fr i,=2024=20Feb=202012=2009:01:30=20-0600|From:=20Pete=20Re snick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Thomas=20Stockhammer=20<stockh ammer@nomor.de>|CC:=20David=20B=20Harrington=20<dbharring ton@comcast.net>,=20Luby=20Michael=0D=0A=09<luby@qualcomm .com>,=20<fecframe-chairs@tools.ietf.org>,=20<fecframe@ie tf.org>|Subject:=20Re:=20Pete=20Resnick's=20Discuss=20on =20draft-ietf-fecframe-rtp-raptor-05:=0D=0A=20(withDISCUS S=20and=20COMMENT)|References:=20<20111029191259.724.2906 7.idtracker@ietfa.amsl.com>=09<843F8E40A07840AFA61B3C3944 F5D7FA@davidPC>=09<4EB2356B.1060801@qualcomm.com>=20<E7F8 D461-E40C-4305-A44F-E3EC533468A7@nomor.de>=20<4ED049F2.20 30306@qualcomm.com>=20<6FF946CE-A73E-42E6-A582-505D9AF0B0 1E@nomor.de>=20<1F1244790E67477DBA4BDBD8491B999A@davidPC> =20<965B818A89DA4E01B31C55CDC3294861@davidPC>=20<46031464 -78F5-4B08-B0C4-9A59CFAF8E5D@nomor.de>|In-Reply-To:=20<46 031464-78F5-4B08-B0C4-9A59CFAF8E5D@nomor.de> |Content-Type:=20text/plain=3B=20charset=3D"windows-1252" =3B=20format=3Dflowed|Content-Transfer-Encoding:=208bit |X-Originating-IP:=20[172.30.48.1]; bh=g8Mav76eenTapMilLJxA9Lq4iAfZuNOjg4JdqlEWmB4=; b=w62qnSRA08RfN4017Auek6Th0njI1/2feevSQX22gahMjFlg2pLKb9/9 XE6TtRx9ZlC4FIMwhQqjcVqEl31+PTOW0lg91YCEbpxzQDKl84BqJqGmm NY56SF9/VPKUFA365SdQ82bzC5KMXxCqoK8M4w2VW6DnFOy9bdyD1O3P8 s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6629"; a="166196126"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 24 Feb 2012 07:01:34 -0800
X-IronPort-AV: E=Sophos;i="4.73,476,1325491200"; d="scan'208";a="186803487"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 24 Feb 2012 07:01:34 -0800
Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 24 Feb 2012 07:01:33 -0800
Message-ID: <4F47A64A.4020206@qualcomm.com>
Date: Fri, 24 Feb 2012 09:01:30 -0600
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Thomas Stockhammer <stockhammer@nomor.de>
References: <20111029191259.724.29067.idtracker@ietfa.amsl.com> <843F8E40A07840AFA61B3C3944F5D7FA@davidPC> <4EB2356B.1060801@qualcomm.com> <E7F8D461-E40C-4305-A44F-E3EC533468A7@nomor.de> <4ED049F2.2030306@qualcomm.com> <6FF946CE-A73E-42E6-A582-505D9AF0B01E@nomor.de> <1F1244790E67477DBA4BDBD8491B999A@davidPC> <965B818A89DA4E01B31C55CDC3294861@davidPC> <46031464-78F5-4B08-B0C4-9A59CFAF8E5D@nomor.de>
In-Reply-To: <46031464-78F5-4B08-B0C4-9A59CFAF8E5D@nomor.de>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.30.48.1]
X-Mailman-Approved-At: Wed, 07 Mar 2012 10:27:11 -0800
Cc: David B Harrington <dbharrington@comcast.net>, fecframe-chairs@tools.ietf.org, fecframe@ietf.org
Subject: Re: [Fecframe] Pete Resnick's Discuss on draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2012 15:01:36 -0000

This addresses my DISCUSS issue. I've cleared. I've left in the 
remaining two comments in my ballot. You may address them if you like, 
or ignore them. That's up to you, Dave, and the WG.

Thanks for addressing the issues.

pr

On 2/24/12 7:35 AM, Thomas Stockhammer wrote:
> Dave, Pete,
>
> I have uploaded a new version.
>
> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-07.txt
>
> Inline how the comments had been addressed:
>
>    
>> In section 10.3, please consider explaining when you would not follow
>> "SHOULD be sent in a separate RTP session" - give guidance on when a
>> single
>> session is appropriate. Likewise, why is using CNAME to associate the
>> sessions
>> only a MAY? Unless there are strong reasons to define and use an
>> alternative
>> mechanism, this would be better off as a MUST.
>>      
> [T] This has been changed as follows:
> "If the repair RTP session is sent in a separate RTP session the two sessions MUST be associated using RTCP CNAME."
>
> The association of repair and source RTP session is not part of the RTCP usage, so this recommendation is removed.
> The choice of whether running this in the same session of in separate session is really deployment specific.
> However, if they are in different sessions, then for association the usage of the same RTCP CNAME is mandated.
>
>
>    
>> and update the document to not use RFC2119 langauge in the template
>> section.
>>      
> [T] This addresses the DISCUSS from Pete. The new text does not include any RFC2119 language.
> "The default value of this parameter (when it does not appear explicitly) is 'A'."
>
> Please let me know if this covers all the remaining concerns.
>
> Thanks
>
> Thomas
>
>    
>> Once we hear from avtcore, you can cut a new revision.
>>
>> thanks,
>> dbh
>>
>>
>>      
>>> -----Original Message-----
>>> From: David Harrington [mailto:ietfdbh@comcast.net]
>>> Sent: Monday, December 05, 2011 10:49 PM
>>> To: 'Thomas Stockhammer'
>>> Cc: fecframe-chairs@tools.ietf.org
>>> Subject: RE: Pete Resnick's Discuss on
>>> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)
>>>
>>> Hi,
>>>
>>> Please change the text in the template sections to not use RFC2119
>>> language.
>>> Pete suggests:
>>> "The default value of this parameter (when it does not appear
>>> explicitly) is 'A'."
>>> I think that is sufficiently clear.
>>>
>>> You can make sure the text elsewhere shows this "A" default is a
>>> normative requirement, using rfc2119 language.
>>>
>>> Please publish another revision with this fix, so we can move
>>>        
>> forward.
>>      
>>> I have asked Robert to check the current revision and clear if he is
>>> satisfied; you might want to wait a couple days to see if he wants
>>>        
>> any
>>      
>>> further changes made.
>>>
>>> Thanks,
>>> David Harrington
>>> Director, IETF Transport Area
>>> ietfdbh@comcast.net (preferred for ietf)
>>> dbharrington@huaweisymantec.com
>>> +1 603 828 1401 (cell)
>>>
>>>        
>>>> -----Original Message-----
>>>> From: Thomas Stockhammer [mailto:stockhammer@nomor.de]
>>>> Sent: Monday, November 28, 2011 1:12 AM
>>>> To: Pete Resnick
>>>> Cc: draft-ietf-fecframe-rtp-raptor@tools.ietf.org;
>>>> fecframe-chairs@tools.ietf.org; David Harrington; 'The IESG'
>>>> Subject: Re: Pete Resnick's Discuss on
>>>> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)
>>>>
>>>> Pete,
>>>>
>>>> inline comments on the comments resolution …
>>>>
>>>>          
>>>>>>>>> Specific problems:
>>>>>>>>>
>>>>>>>>> Section 3: "MAY" is not appropriate here. You're not
>>>>>>>>>                    
>> defining
>>      
>>>>>>>>> a protocol option; you're saying that repair packets can be
>>>>>>>>> generated.
>>>>>>>>>
>>>>>>>>>                    
>>>>>> [T] To avoid the may here it says now:
>>>>>> "The Raptor and RaptorQ codes are efficient block-based
>>>>>>              
>>>> fountain codes, meaning that from any group of source packets
>>>> (or 'source block') an one can generate an arbitrary number
>>>> of repair packets."
>>>>          
>>>>>>              
>>>>> Works for me (though there seems to be a typo in
>>>>>            
>>>> [T] Thanks! Typo fixed!
>>>>
>>>>          
>>>>>            
>>>>>>> I must say that, try though I might, I can't understand
>>>>>>>                
>>>> how an implementer might choose to decide that a marker bit
>>>> of 0 means last packet and 1 means otherwise. That one sounds
>>>> like a definition of the bit, not anything that can be an
>>>> implementation choice that requires a 2119 requirement.
>>>>          
>>>>>>>                
>>>>>> [T] I understand the comment from Pete that this may also
>>>>>>              
>>>> be interpreted as a definition. But still it is expected that
>>>> the bit is set accordingly and the implementation can write
>>>> code to identify the last packet in the source block and set
>>>> the marker bit to 1. So I would prefer to stick with the SHALL
>>>>          
>> here.
>>      
>>>>>>              
>>>>> I still disagree, but it sounds like I'm "in the rough"
>>>>>            
>>>> part of the consensus. :-)
>>>>
>>>> [T] See other discussion, I am still trying to understand the
>>>> exact issue.
>>>>
>>>>          
>>>>>> I don't think you can use this payload format for anything
>>>>>>              
>>>> different than Raptor and RaptorQ, at least this is not
>>>> considered. It is also the case that different media codecs
>>>> generally each defines different payload formats unless the
>>>> payload formats are generic. I would assume the same applies
>>>> here and this is mostly because we know that it works with
>>>> Raptor and RaptorQ, but we do not know if it works with
>>>> anything different.
>>>>          
>>>>>> I left the second "SHALL" because this is what an
>>>>>>              
>>>> implementor is expected to do.  To create an RTP payload that
>>>> contains FEC Repair Payloads.
>>>>          
>>>>>>              
>>>>> (*Shrug*) I don't think it's necessary.
>>>>>            
>>>> [T] Still not sure what would be the appropriate text then?
>>>> Is it not mandated that the implementor implements the
>>>> normative parts of the two docs?
>>>>
>>>> Thomas
>>>>          
> ---
> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
> Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102