Subject: RE: [rohc] RE: I-D ACTION:draft-ietf-rohc-context-replication-04. txt

From: [email-masked]
Date: Tue, 28 Sep 2004 08:09:48 -0400

> It seems to me that a decompressor would rather send a NACK 
> in case of a problem because of 2), instead of being mandated 
> to ACK. 

Of course the decompressor MUST send NACKs in case the base
context does not exist. There is no disagreement here.

What I propose is to require the compressor MUST wait for ACKs 
of IR-CR before it moves out higher state. The benefit is that
it avoids the decompression failure and the forced packet dropping
by decompressor before the compressor receives the NACK.

Looking from the other side, what do you think is the disadvantage 
of mandating ACKs? (Lars-Erik brought up his concern about U-mode, 
which I have addressed. )

Br, Zhigang

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Tue, 28 Sep 2004 14:41:10 +0200

Hi Zhigang and others,

As all of you agreed earlier in the same thread 
(http://www1.ietf.org/mail-archive/web/rohc/current/msg02603.html), the Context 
Replication draft should not preclude replication of any control fields, the 
replication or non-replication of these fields should be defined per profile.

To me, mandating ACKs would be against the normal operating assumptions of both 
the bidirectional mode of ROHC-TCP as well as O-mode from 3095 since these rely 
on optimistic approach and NACKs to handle this. Mandating the compressor to 
wait for an ACK/NACK before being allowed to use the new context to me means 
that these modes are not fully compatible with CR, and therefore this 
requirement is not useful to put in the CR draft.
If a profile is defined using CR wants to mandate this, then fine, but the 
"framework" CR draft should not put requirements that limit the possible future 
profiles this way.

Just my 2 cents.

/Kristofer Sandlune, Effnet AB