[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0
Hi,
I am aware of this, but I think it is worth to indicate there may be potential problems or low compression efficiency issues because of this. Think of what happens if B does not send the returned parameters: A has to send the bytecode in every message. In such a situation B proves to perform better than than A, unless A is brave enough not to send the bytecode again.
Anyway, the RFC does not mandate that "it has to assume that the receiver can't save state." (As far as I can remember, it is not even recommended.) It may be logical, but in situations when every byte spared is a success, the temptation is great to make "reckless" implementations that do not care of such things. Assumptions amongst "friend" softwares work well, which may pave the way before these, handicapping others.
BR/Zacco
-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Friday, February 07, 2003 11:51 AM
To: 'Lajos Zaccomer (ETH)'; 'zhigang.c.liu@nokia.com'; rohc@ietf.org
Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0
Hi Zacco,
It's an implementation decision at the receiver whether to
announce that SMS > 0 or not. Note however that if the
receiver chooses not to do this, then the sender MUST
assume that SMS = 0 (in other words it has to assume that
the receiver can't save state).
Regards,
Richard
> -----Original Message-----
> From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se]
> Sent: Friday, February 07, 2003 10:18 AM
> To: Price, Richard; 'zhigang.c.liu@nokia.com'; rohc@ietf.org
> Subject: RE: [rohc] SigComp state creation request, requested
> feedback,
> a nd SMS = 0
>
>
> Hi,
>
> This may help, but sending the returned parameters is not
> mandatory, moreover not recommended!
>
> BR/Zacco
>
> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk]
> Sent: Friday, February 07, 2003 10:59 AM
> To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org
> Subject: RE: [rohc] SigComp state creation request, requested
> feedback, a nd SMS = 0
>
>
> > Hi,
> >
> > (This is not specified on RFC 3320, so I want to double check.)
> >
> > If a message carries state creation request but the receiving
> > endpoint has SMS = 0, I understand that the message can still be
> > accepted but the state creation request will be rejected.
>
> Hi Zhigang,
>
> That's right - state creation requests can be rejected due to lack
> of memory, even if the decompressed message is accepted.
>
> > Now, what about the requested feedback carried in the message?
> > Will it be returned?
>
> The requested feedback can still be returned even if SMS = 0.
>
> > If yes, that means the sender must not rely on feedback to determine
> > if the state has been successfully created. Then, is the answer no?
>
> The sender can still rely on the feedback to determine if the state
> has been successfully created, but only if it takes into account the
> returned SigComp parameters as well. In particular it needs to check
> that the receiver has advertised SMS > 0.
>
> SigComp-Extended has the following to say on the subject:
>
> Note: There is a possibility that state(S) is discarded due to lack
> of state memory even though the announcement information is
> successfully forwarded. This possibility must be taken into account
> (otherwise a decompression failure may occur); this can be done by
> using the SigComp parameter state_memory_size which is announced by
> the SigComp feedback mechanism. The endpoint can use this parameter
> to infer if a state creation request has failed due to lack of
> memory.
>
> Hope this helps!
>
> Regards,
>
> Richard
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc