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

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Thu, 18 Aug 2005 16:59:47 +0200

Hi,

I agree with Mark that it is dangerous to allow the decompressor to drop a context even for connection-based protocols, since you're still probably guessing. 
And even if you have out-of-band ways of knowing the connection has ended, the decompressor has still promised to provide context for MAX_CID+1 contexts, so the potential gain of this is not that useful.

If we're to allow this, we must state the dangers involved and require that this is only done when the decompressor can send STATIC-NACKs in the case where the the guess was wrong. Therefore, I'd say we're better off not allowing it.

Another issue, why does the text say that a _compressor_ needs to keep context? If a compressor just chooses to utilize a small part of the CID space negotiated, where's the harm in that? Also, if a compressor decides to throw out context partially through a flow, it will just have to go back to IR state and/or re-map the flow to a new CID for the next packet, which is no danger to interoperability.

/Kristofer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark West
> Sent: den 18 augusti 2005 17:42
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [rohc] Minor correction in the RFC 3095 
> implementer's guide
> 
> 
> 
> 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
> >
> > 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
> >
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 19 Aug 2005 08:06:21 +0200

> I agree with Mark that it is dangerous to allow the 
> decompressor to drop a context even for connection-based 
> protocols, since you're still probably guessing. 
> And even if you have out-of-band ways of knowing the 
> connection has ended, the decompressor has still promised to 
> provide context for MAX_CID+1 contexts, so the potential gain 
> of this is not that useful.
> 
> If we're to allow this, we must state the dangers involved 
> and require that this is only done when the decompressor can 
> send STATIC-NACKs in the case where the guess was wrong. 
> Therefore, I'd say we're better off not allowing it.

OK, you've raised a good point, I think we should then keep
the original text. Better be on the safe side, and we should
not make things too complicated (which I think would be the
case if we tried to add enough discussion to make everything
clear).

> Another issue, why does the text say that a _compressor_ 
> needs to keep context? If a compressor just chooses to 
> utilize a small part of the CID space negotiated, where's the 
> harm in that? Also, if a compressor decides to throw out 
> context partially through a flow, it will just have to go 
> back to IR state and/or re-map the flow to a new CID for the 
> next packet, which is no danger to interoperability.

Hmmm, this is actually a comment on the original text, which
has been there for a long time. However, that does not mean
you are wrong. 

Of course there is no harm in (as a compressor) using just a
part of the negotiated space, that would be the similar to not
having initiated all CID's yet. The second example you give
contains several examples in one, and I do not see the point
you are making. Why would a compressor re-map a flow to a new
CID?

/L-E

---

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Fri, 19 Aug 2005 08:29:58 +0200

> you are making. Why would a compressor re-map a flow to a new

I was simply trying to illustrate that even if the compressor discards context(s), it will still have knowledge of MAX_CID and will not map any contexts to CID number above that number. Therefore, it is always safe for the compressor to selectively discard context even when the decompressor is forced to keep context.

/Kristofer

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 19 Aug 2005 08:52:58 +0200

> I was simply trying to illustrate that even if the compressor 
> discards context(s), it will still have knowledge of MAX_CID 
> and will not map any contexts to CID number above that 
> number. Therefore, it is always safe for the compressor to 
> selectively discard context even when the decompressor is 
> forced to keep context.
> 
> /Kristofer

OK, then we should adjust the text to only target the
decompressor!

--------------------------------------------------------------
7.1. The 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, the decompressor also agrees to provide
memory resources to host at least MAX_CID+1 contexts, and an
established context with a CID within this negotiated space
MUST be kept by the decompressor until either the CID gets
re-used, or the channel is taken down or re-negotiated.
--------------------------------------------------------------

/L-E