Subject: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt

From: Aniruddha Kulkarni <[email-masked]>
Date: Fri, 22 Apr 2005 12:14:08 +0200

Hi,

    I have following comments on the draft, I have tried not to repeat the
comments made by others but there may still be some repetitions.

1. section 5.1.2.1 "The compressor removes values smaller than..."
this should be "...older than...".

2. section 5.2.1 "When using this encoding method, the decompressor 
discards...".
This should be "..., the compressor discards..." (refer 3095 section 
4.5.4, para 4).
    I agree with others on the point that timer-based compression is not
"functionally incompatible" with reordering. It suffers in same way as 
scaled-timestamp
encoding would.

3. section 6.1.1.2 , Avoiding the "missing reference" problem
If the decompressor implements the context updating logic of section 
6.1.2.1 and
compressor is aware of that (by means of standardization), why would it 
delay
advance in sliding window?

4. section 6.1.2.1 , Will the addition of "The decompressor should not 
deliver
the sequentially late (with respect to the reference) non-updating packet to
upper layer." handle case for both updating and non-updating packets?
    
5. section 6.1.2.2 "Note that if the decompressor does not make this 
adjustment
to its feedback, packet losses or context damages will not increase".
    It is confusing, could it mean that "if decompressor does make the 
adjustment,
packet losses/context damages will increase" or does it mean "even if 
decompressor
does not make the adjustment, losses/damages will not increase". Can it 
be made
bit clear?

Aniruddha Kulkarni

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 3 May 2005 09:37:43 +0200

Ok, then I see what you were aiming at. I'll look at this and
see what I can come up with, along with the rest of your issues.

Expect a summary of proposals for how to address both your 
comments and Marks, I should be able to do this later on today
or (not later than) tomorrow morning.

Thanks!
/L-E

> -----Original Message-----
> From: Aniruddha Kulkarni [mailto:[email-masked]]
> Sent: den 3 maj 2005 09:20
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [rohc] Review: draft-ietf-rohc-over-reordering-02.txt
> 
> 
> Well, the section heading only says "Bi-directional Reliable Mode 
> (R-mode)", so
> I suggested handling for both updating and non-updating 
> packets to make 
> it complete.
> 
> ---Aniruddha
> 
> Lars-Erik Jonsson (LU/EAB) wrote:
> 
> >Aniruddha,
> >
> >Thanks for checking the document. Before I respond to all issues
> >I agree with you on, I'd like to understand better what you mean
> >with the following:
> >
> >  
> >
> >>4. section 6.1.2.1 , Will the addition of "The decompressor 
> >>   should not deliver the sequentially late (with respect to
> >>   the reference) non-updating packet to upper layer." handle
> >>   case for both updating and non-updating packets?
> >>    
> >>
> >
> >Do you mean something is missing in 6.1.2.1? I do not understand
> >the intention here. 6.1.2.1 only addresses updating packets, as
> >it is about avoiding the "missing reference problem", which only
> >concerns updating packets.
> >
> >Rgds,
> >/L-E
> >  
> >
> 
>

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 10 May 2005 13:46:06 +0200

> Your suggested updates address my comments. I am 
> wondering; if there is no reliable way to detect
> reordering, then are the last para in section 
> 6.1.2.2 and section 6.1.2.3 still relavent?

Yes, I believe they are. 6.1.2.3 only says "if reordering
can be the cause", i.e. I read it as "if the decompressor
knows this channel may cause reordering and decompression
fails, an additional local repair may be attempted".

For the last paragraph of 6.1.2.2, I suggest the following
minor re-write. 

OLD:
   Acknowledgements and sequentially late packets

      Reordered feedback (or feedback for packets received out-of-order)
      will not cause problems (see section 5.1.4). However, the
<     decompressor should not send feedback for sequentially late
<     packets, as the current state of the context will better reflect
      the compressor context than the content of the reordered packet.

NEW:
   Acknowledgements and sequentially late packets

      Reordered feedback (or feedback for packets received out-of-order)
      will not cause problems (see section 5.1.4). However, the
>     decompressor should not send acknowledging feedback for a packet
>     if it is reasonable to believe it is sequentially late (e.g. by
>     just looking at the sequence number of the packet), as the current
      state of the context will better reflect the compressor context
      than the content of the reordered packet.

Rgds,
/L-E