Subject: Re: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt

From: Aniruddha Kulkarni <[email-masked]>
Date: Wed, 01 Jun 2005 16:39:59 +0200

Hi,

    We do have complete implementation of LLA including the normative
changes in implementor's guide. Probably there exists other implementations
or customer deployments.                                                  
    The proposal has it's merits but I agree with Lars-Erik that it is 
good only
for corner cases.                                 
    So I prefer to maintain status quo, follow the implementor's guide 
as it is now.

Aniruddha Kulkarni
Effnet AB

Lars-Erik Jonsson (LU/EAB) wrote:

>Ghyslain,
>
>I agree with your technical point, and if this had been suggested
>a year ago, I had probably bought it without any concerns. 
>
>  
>
>>>Finally, and most important, this is the solution we came up
>>>with as our official solution when the problem was observed
>>>a year ago. Before we change that today, I think we should have
>>>really good arguments.
>>>      
>>>
>>See above. Furthermore, my understanding of the document that 
>>you are referring to (LLA implementer's guide) is that this 
>>is an informational draft, nothing normative. Now that we've 
>>submitted a new draft to make the corrections normative, this 
>>is where we define the "official solution" from my perspective. 
>>    
>>
>
>3242 is non-interoperable with CSP, so we had to come up with a
>solution. The agreed and official WG solution has been captured in
>the LLA implementer's guide, in the same way as we have done for
>RFC3095 with the ROHC implementer's guide. The LLA implementer's
>guide is a draft, correct (a draft has no category), but it is the
>most normative source that has been available. The solution has
>been stable, and we have not identified more flaws, therefore it
>is time to replace 3242 with a corrected RFC that incorporates
>this fix.
>
>So, the main argument I see for keeping the current solution is
>that it has been there for a year, and the actual performance
>argument against it is rather small.
>
>The argument for doing a change is technical, we would not "waste"
>two bytes in certain corner-cases. Also, if deployment of the
>existing solution is insignificantly limited, it might be a good
>idea to do this change.
>
>I do not see an obvious way out here, one may question the actual
>problem with doing this change, but one may also question the
>efficiency argument in favour of the change. However, right now
>I would say we should do this change, if we do not get more input
>from others, preferably from those who have implemented the RFC
>with the existing fix.
>
>BR
>/L-E
>
>_______________________________________________
>Rohc mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rohc
>  
>

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 2 Jun 2005 10:31:18 +0200

Hi Aniruddha,

In the interest of closing this discussion...

My previous mail was mainly "for the record" because this is what I think is the better solution, but I have no special interest into this question - so statu quo is fine for me - I was simply asked to comment on the document. Case closed.

However, I wonder how "normative" the implementer's guide really is (as well as how much "deployment" really weights) in such case, when a part of an RFC is known not to the be interoperable and when other standards (IS-835-C) will need to be amended in order to "validate" the fix. This seems possible either by including text from the implementer's guide or when the only alternative is to wait for the new RFC that corrects the problem - provided the profile number remains unchanged (which alternatives both make the document much less relevant). Just a thought about the argumentation in this discussion ; )

/Ghyslain

> -----Original Message-----
> From: Aniruddha Kulkarni [mailto:[email-masked]]
> Sent: den 1 juni 2005 16:40
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: Ghyslain Pelletier (LU/EAB); [email-masked]
> Subject: Re: [rohc] Small comment on
> draft-ietf-rohc-rtp-lla-impl-guide-01.txt
> 
> 
> Hi,
>

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 2 Jun 2005 10:50:52 +0200

Ghyslain,

I think using the word "normative" is indeed not correct here,
in that regard I fully agree with you. What the implementer's
guide do represent, however, is the current official WG solution
to the problem(s) identified. Formally, this has no special
value as it is just captured by an internet-draft, but I do
consider this to represent WG (rough) consensus. As long as we
have not shipped an update to the RFC in question, of course
we can make changes to these official WG solutions if we get
good arguments for doing so and can reach (rough) consensus
for a change. However, changing status quo that has not been
questioned for a year will require more argumentation than the
alternative (i.e. to keep status quo). Implementations do not
wait for us to publish an updated RFC.

If RFC's were published in days instead of months (years), we
would probably ship new updated protocols much quicker (for
each problem identified and resolved), but that is not reality.
In ROHC, we have therefore captured our problem solutions in our
"imlementer's guide" documents. These form the "current state"
of WG consensus regarding how problems with our protocols are
to be addressed. This procedure is not optimal, and the formal
meaning of these documents can be questioned, but life is not
always perfect.

Rgds,
/L-E

> However, I wonder how "normative" the implementer's guide 
> really is (as well as how much "deployment" really weights) 
> in such case, when a part of an RFC is known not to the be 
> interoperable and when other standards (IS-835-C) will need 
> to be amended in order to "validate" the fix. This seems 
> possible either by including text from the implementer's 
> guide or when the only alternative is to wait for the new RFC 
> that corrects the problem - provided the profile number 
> remains unchanged (which alternatives both make the document 
> much less relevant). Just a thought about the argumentation 
> in this discussion ; )
> 
> /Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 2 Jun 2005 12:40:15 +0200

Just some more thoughts... to explain my previous line of thinking.

> Implementations do not wait for us to publish an updated RFC.

I am not sure who's problem this is... and my point is that I don't think that this _can_ apply to LLA because of 3GPP2 standards dependencies.
 
> meaning of these documents can be questioned, but life is not

I don't have a problem with this procedure in general, when it applies and where there is little alternative. 

My point was to question that: because it is called an "implementer's guide", the procedure you describe automagically applies. In the case of LLA, for which implementation and deployment is dependent of another standard body, what you described is not really a factor since in this case implementations do wait for publication of the standards and dependencies of this other standard body (unless extreme force majeur), including in this case either including the fix into an addendum (be it the solution itself or the reference to the updating RFC). Furthermore, there is a risk if/when doing so that the question regarding how to solve this is brought up again.

In this particular case, there is also another aspect. Of course it is possible to never send IR/IR-DYN using the CSP and use the frame stealing "feature" of 3095 to blank the application payload. However, this means that to avoid the 2 additional octets of the CSP that is unnecessary if sending IR and IR-DYN in a CSP, LLA is now bound to perform 3095 frame stealing. Personnally, I think that frame stealing in 3095 is not defined as a feature (one has to understand how the specs works to realize that it is ok to use it this way), I think that if LLA is to rely on this for IR/IR-DYN instead of the CSP then it should be clearly explained in the updating RFC. Finally, maybe another relevant question: if we go forward with an update to 3095, do we all consider frame stealing with IR/IR-DYN as a feature, or do we consider it as a "hole" in the specs that might be fixed/removed? With the current solution proposed for the CSP, we make LLA dependant on this in order to be as efficient as it can be.

I am still fine with statu quo on this matter.

/Ghyslain