Subject: [rohc] Minor correction in the RFC 3095 implementer's guide

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 18 Aug 2005 15:24:45 +0200

Ghyslain pointed out that section 7.1, as currently written, do
not take into consideration how contexts for connection-oriented
flows can be discarded when the end-to-end connection is closed.
Since the intent with that section was to be profile-independent,
I have therefore rewritten section 7.1 with this in mind:

--------------------------------------------------------------
7.1. Compressor and decompressor MUST keep MAX_CID contexts

  As part of the negotiated channel parameters, compressor and
  decompressor have through the MAX_CID parameter agreed on the
  highest context identification (CID) number to be used. By
  agreeing on MAX_CID, both compressor and decompressor also
  agrees to provide memory resources to host at least MAX_CID+1
  contexts, and an established context with CID within this
  negotiated space MUST be kept by both compressor and
  decompressor at least until either the CID gets re-used, the
  end-to-end connection is closed (connection-oriented flows
  only), or the channel is taken down or re-negotiated.
--------------------------------------------------------------

BR
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]                      /"\
Phone: +46 8 404 29 61                                      \ /
Fax: +46 920 996 21               ASCII Ribbon Campaign      X
Home: +46 8 501 64 503         against HTML email & vCards  / \

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

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

---

From: Mark West <[email-masked]>
Date: Thu, 18 Aug 2005 15:42:06 +0000 (GMT)

Hmmmm...

"contexts for connection-oriented flows can be discarded when the
end-to-end connection is closed."

Can they?

What worries me slightly about this is the assumption that you can 'know'
when an end-to-end connection has closed. Let's take TCP as a handy
example of a connection-oriented protocol.

Trivially, if the compressor/decompressor are not co-located with the
communication end-points, or in a restricted topology, then you can't
guarantee to spot connection-close without explicit signalling.  (You
might not even see the FIN packets.)

But, even if there's co-location / I guarantee to see all packets:

   [A]                          [B]
    |                            |
 <FIN_WAIT_1>                    |
    |------- FIN (seq = n) ----->|
    |                         <CLOSE_WAIT>
    |                            |
    |<------ ACK (seq = n+1) ----|
    |                            |
    |                         <LAST_ACK>
    |<------ FIN (seq = m) ------|
 <TIME_WAIT>                     |
    |                            |
    |------- ACK (seq = m+1) --->|
    |                         <CLOSED>

You can't tear down the connection at 'A' (at least, you shouldn't) when
it enters TIME_WAIT, because otherwise you prevent retransmission of the
FIN from 'B'.

You *can* tear down the context at 'B' when it enters CLOSED, but if
you're not co-located with 'B', how do you *know* it's received the ACK?

Maybe you could drop the state after seeing both FINs and ACKs, and then
waiting the max possible 2MSL.  But, hang on!  Will the compressor and
decompressor dropt the state at exactly the same time?  If the
decompressor drops state after some assumption of 2MSL and the compressor
doesn't, then [valid] re-use of the connection outside of the
TIME_WAIT-ing host's 2MSL may cause the compressor to re-use a context
that the decompressor has dropped (but which the compressor thinks is
still there).  Couldn't it?

This is all very hand-waving (unsurprising for anyone who's seen me give a
presentation...), but raises a concern.

If this is being proposed, then I'd like to see a more detailed analysis
of how it can be done without risking discarded packets (== loss of
transparency).

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Thu, 18 Aug 2005, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Thu, 18 Aug 2005 15:24:45 +0200
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: [email-masked]
> Subject: [rohc] Minor correction in the RFC 3095 implementer's guide
>