RE: Last-call (RE: [rohc] I-D ACTION:draft-ietf-rohc-rtp-07.txt)

[zhigang.liu@nokia.com]

Hi Mikael,

I actually thought about adding an explicit case "d" for NC state.
But I changed my mind because the whole section 5.3.2.2.3 is about

1) attempting local repair first, and if it fails, 
2) trying to determining the cause of a CRC failure, and 
3) determining whether to do downward state transition, and
4) determining whether to send feedback.

The NC state is somewhat out of place here as 1) to 3) do
not make sense for NC state in ALL modes. And 4) does not
apply for NC state in U-mode. That was the reason why I suggested 
to treat NC state separately at the end of the section. 
But you're right that my text overlooked the last sentence
in c) which does apply to NC state. Besides, your notes
about IR and IR-DYN are very good.

So, in summary, how about the following changes to 5.3.2.2.3?
1) Restructure as you proposed
2) To clarify the special case of NC state due to the reasons 
above, add the following text after your notes about IR and IR-DYN:

   "Except where it is explicitly stated, the rest of this section
   does not apply to the decompression logic in No Context state."

By the way, we are talking about decompressor, not compressor. 
But I perfectly understand this typo by looking at the time field
of your email. :-)

Finally, regarding the text in R-mode on page 66, I think we can safely
remove it. Your proposed replacement (see below) is already covered 
in the last paragraph of 5.5.2.1. What do you think?

Br,
Zhigang

> -----Original Message-----
> From: ext Mikael Degermark [mailto:micke@CS.Arizona.EDU]
> Sent: Monday, February 05, 2001 8:30 PM
> To: zhigang.liu@nokia.com
> Cc: cabo@tzi.org; rohc@cdt.luth.se; micke@CS.Arizona.EDU
> Subject: RE: Last-call (RE: [rohc] I-D
> ACTION:draft-ietf-rohc-rtp-07.txt)
> 
> 
> At 06:51 PM 2/5/01 -0600, zhigang.liu@nokia.com wrote:
> >Hi Carsten and others,
> >
> >In feedback logic (O-mode) (section 5.4.2.2, page 61), it says:
> >
> >NC:  - (clip)
> >     - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR
> >       packet has failed the CRC check, use the logic in section
> >       5.3.2.2.3 to decide if a NACK(O) should be sent. (clip)
> >
> >However, there is no text about NC state in section 5.3.2.2.3 
> >(page 56).
> 
> Well, there is but unfortunately baked into the text about Static Context.
> There needs to be text in 5.3.2.2.3 to specify the behavior for U-mode in 
> NC state, so we could restructure somewhat to make this clearer 
> and say (on pg 56-57):
> 
> "In the Static Context state: ..... The compressor moves to 
> the No Context state. 
> 
> In the No Context state: The compressor discards all packets until a
static update (IR)
> which passes the CRC check is received. In O-mode and R-mode, feedback is
sent 
> according to sections 5.4.2.2 and 5.5.2.2, respectively."
>  
> 5.3.2.2.3 as it stands is clearly aimed at type 0, 1, or 2 headers.
> IR or IR-DYN aren't really treated much in 5.3.2.2.3. We could put 
> the following text after the cases on page 55 to clarify the logic
> for IR and IR-DYN.
> 
> "Cases 2 and 3 do not apply to IR packets.
> Case 3 does not apply to IR-DYN packets."
> 
> >So, I'd like to suggest following modifications:
> >
> >1) Add following text at the end of section 5.3.2.2.3
> >
> >   Note that this section does not apply to CRC failures that
> >   occur during No Context state. The actions taken by the
> >   decompressor in those cases will be described in the decompression 
> >   logic section of each mode.
> 
> 1) would leave U-mode implementors in the dark. Instead, 
> I would think it is better to just restructure the current text to have an
explicit
> case for NC state (as I proposed above), which would more clearly define
the
> behavior for U-mode in NC state, and there point forward to the
appropriate
> sections for O- and R-mode. 
> 
> >2) Modify section 5.4.2.2 as follows:
> >
> >NC:  - (unchanged)
> >     - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR
> >       packet has failed the CRC check, send a STATIC-NACK(O),
> >       subject to the considerations at the beginning of section 
> >       5.7.6.
> 
> Yes, the pointer should be to 5.7.6 and not 5.3.2.2.3.
> 
> >3) Add following text as the third bullet of section 5.5.2.2 
> (page 65):
> >
> >   - In No Context state, send a STATIC-NACK(R) when receiving a
> >     non-IR packet, subject to the considerations at the beginning
> >     of section 5.7.6. The decompressor SHOULD NOT send STATIC-NACK(R)
> >     when receiving an IR packet that fails the CRC check, as the 
> >     compressor will stay in IR state and thus continue sending IR 
> >     packets until a valid ACK is received (see section 5.5.1.2). 
> >
> >4) Remove the following redundant text from section 5.5.2.2 (page 66)
> >
> >   Negative feedback is sent according to the same principles as in
> >   5.3.2.2.3. See also the previous section.
> 
> Regarding 4): Isn't it appropriate to instead say:
> 
> "Context damage is detected according to the principles in 5.3.2.2.3."
> 
> Otherwise, there would not be any specified mechanism for
> detecting context damage. 
> 
> >Comments?
> 
> Yes, comments?
>