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

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 20 May 2005 16:30:00 +0200

One small comment to section 3 "CSP Packet Format" regarding the proposed new format - the new proposed format means that any RHP packet carried within the CSP must carry the additional 2 octets RTP Payload Length Field.
 
However, this is not necessary for IR and IR-DYN packets - it could then be possible to specify that this field is present only for RHP packet types that are of a type other than IR and IR-DYN, so that when these larger headers are carried within the CSP the additional overhead of the new field could be avoided. Doing so, I might be useful for parsing to move the RTP Payload Length Field at the end of the CSP instead, so that the RHP packet type is always at the same position no matter if the RTP Payload Length Field is present or not.
 
I understand that for the IR packet there exist another alternative than the CSP in order to do frame stealing, which is more efficient than using the CSP, but yet it seems a better choice to make any alternative as efficient as possible.
 
/Ghyslain
 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 23 May 2005 08:53:38 +0200

Ghyslain,

I can see your point, and I agree that the RTP length is not needed for IR or
IR-DYN CSP's. In general, I also agree we should not waste unnecessary bits,
if not justified by simplicity or other good reasons.

However, I do not see the big deal with this, as the relative extra overhead
is still small. Further, and more important, I think the solution we have is
more straightforward and simple. 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.

So, I think you have a good point, but without more convincing arguments
for the value of changing the current solution, I believe we should stick
to status quo.

By the way, what has been in draft-ietf-rohc-rtp-lla-impl-guide-01.txt
since last year is now, as suggested by Allison, incorporated in 
draft-ietf-rohc-rfc3242bis-00.txt, which is intended to generate a
replacement for rfc3242.

BR
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ghyslain Pelletier(LU/EAB)
> Sent: den 20 maj 2005 16:30
> To: [email-masked]
> Subject: [rohc] Small comment on draft-ietf-rohc-rtp-lla-impl-guide-01.txt
>
>
> One small comment to section 3 "CSP Packet Format" regarding the proposed
> new format - the new proposed format means that any RHP packet carried
> within the CSP must carry the additional 2 octets RTP Payload Length Field.
>
> However, this is not necessary for IR and IR-DYN packets - it could then
> be possible to specify that this field is present only for RHP packet types
> that are of a type other than IR and IR-DYN, so that when these larger
> headers are carried within the CSP the additional overhead of the new field
> could be avoided. Doing so, I might be useful for parsing to move the RTP
> Payload Length Field at the end of the CSP instead, so that the RHP packet
> type is always at the same position no matter if the RTP Payload Length
> Field is present or not.
>
> I understand that for the IR packet there exist another alternative than
> the CSP in order to do frame stealing, which is more efficient than using
> the CSP, but yet it seems a better choice to make any alternative as
> efficient as possible.
>
> /Ghyslain

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 23 May 2005 10:35:16 +0200

> However, I do not see the big deal with this, as the relative 
> extra overhead is still small. Further, and more important, I think the 
> solution we have is more straightforward and simple.

Clearly, simplicity is not something that was the priority when making this profile - it was rather efficiency, and I don't see what it is that is not straightforward in my proposal. The reason why IR and IR-DYN packets don't need to carry this information are quite straightforward as well...

Anyway, I think that the arguments in favor of saving these two octets for IR and IR-DYN packets, even if one could use 3095 frame stealing instead, are rather compelling.

Consider:

1) LLA was made to adapt an application payload rate that is exactly the
  same rate as the synchronized link. As twisted a requirement this might be,
  the reason to do this was the priority to make sure that _every_ single octet
  that could be removed would be removed. 

2) On the links targeted by LLA (IS-95), most likely the IR and IR-DYN
  will have to be segmented using RoHC segmentation
  (already some additional overhead there). Would the addition of these
  redundant two octets for the RTP payload length cause an additional
  segment to be sent, then this is yet another 20 ms of application
  payload that needs to be dropped or delayed (multiply this by the OAA
  approach, i.e. normally 3 such packets must be sent). This can
  certainly happen depending on how the LL frame sizes vary when sending
  these packets (on SO61, the full rate can not be guaranteed for each
  physical frame), there is no way to guarantee that this extra two
  octets will _never_ waste an additional 20 ms frame (times OAA).

Of course, the alternative way to use the (poorly described) frame stealing of 3095 could (should?) also be clarified in the draft as well as an alternative, but yet I'd rather have this one right as well in any case. 

> 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. 
 
> So, I think you have a good point, but without more convincing
> arguments for the value of changing the current solution, I believe we 
> should stick to status quo.

See above. The proposal I made in the previous mail is straightforward and
simple. Please provide arguments _against_ instead. I really don't see
your point with "let's keep things as they are because this is how the've
been" for such a trivial proposal.

> draft-ietf-rohc-rfc3242bis-00.txt, which is intended to generate a

I know, my name's on it ; ) - I guess you meant to notify others of this new submission.
 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Subject: [rohc] Small comment on 
> draft-ietf-rohc-rtp-lla-impl-guide-01.txt
> >
> >

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 23 May 2005 12:11:46 +0200

Ghyslain,

I agree with your technical point, and if this had been suggested
a year ago, I had probably bought it without any concerns. 

> 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