Subject: RE: [rohc] 3GPP2's need for

From: "Sarkar, Biplab" <[email-masked]>
Date: Wed, 15 Nov 2006 17:12:17 +0530

All,

I believe "something is better than nothing". So, until we get the
Rohcv2, why not just have a short term arrangement and keep things
going. After all this short term solution is asking for some new profile
numbers. Since I believe we have enough of those, sparing a few
shouldn't be a big issue.  Since "Special theory" came ahead of "General
Theory" I believe we can have this short term solution for the time
being.

Thanks

Biplab

________________________________

From: West, Mark [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 4:05 PM
To: Trabelsi, Chokri (Chokri); Ghyslain Pelletier (LU/EAB); Thomas
Narten; [email-masked]
Cc: AC Mahendran
Subject: RE: [rohc] 3GPP2's need for

Hi all,

Can I briefly expand upon a (technical) argument made earlier in this
thread..?  Without prejudice to the discussion about what to do about
pursuing this work or otherwise ;-)

I don't recall seeing any discussion in this draft of the effect of
re-ordering on anything other than typical LSB updates.  For example,
updates to a rarely changing field (such as TTL).

The following sequence:

 1) UO-0
 3) UOR-2 + EXT-3 (TTL)
 2) UO-0 (sequentially late)

will cause the delayed packet 2 to decompress incorrectly.

There are various ways that this can be handled (rely on CRC; detect and
discard; detect and correct) some of which may impact the configuration
of the decompressor (k out of n rules).  Whilst it may not be necessary
to define this for interoperability, it does affect 'robustness' and so
some discussion is surely justified..?

In other words, I agree that this should be a relatively uncommon case;
but that doesn't mean it should be ignored!  And what concerns me
slightly more is how many other similar cases may be buried in there...

Cheers,

Mark.

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