[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 all,
I am trying to understand the feedback mechanism provided by SIGCOMP. My
question is based on what happens if a remote endpoint receives a message
which it cannot decompress for whatever reason so we have a DECOMPRESSION
FAILURE.
Can the remote end-point notify the sending end-point that decompression has
failed. The reason I ask this is that the RFC states that feedback is
piggybacked onto a Sigcomp message.
I don't know if I am completely misunderstanding the format of a Sigcomp
message but should it not always contain a compressed message. If a
DECOMPRESSION FAILURE occurs a follow-up message/response cannot be sent.
So can a Sigcomp message be sent for the sole purpose of DECOMPRESSION
FAILURE
notification without being accompanied by a compressed message?
Any help at all would be greatly appreciated
Regards,
Val
-----Original Message-----
From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Lajos
Zaccomer (ETH)
Sent: 07 February 2003 11:08
To: 'Price, Richard'; 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,
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
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for
the person to whom it is addressed. Its contents may be protected by legal
and/or professional privilege. Should it be received by you in error please
contact the sender at the above quoted email address. Any unauthorised form
of reproduction of this message is strictly prohibited. The Institute does
not guarantee the security of any information electronically transmitted and
is not liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the sender nor
for any delay in its receipt.
----------------------------------------------------------------------------
------------
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
----------------------------------------------------------------------------------------
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc