Subject: [rohc] sigcomp issue lejo-10

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 17:14:53 +0200

> Security implications???

The feedback data is not to be passed to the compressor unless a valid session ID is presented. To my knowledge that is no difference from what is in SigComp-05.

> What would be the meaning of I=0?
> The receiver dumping all its locally available state (i.e., lots)?
> There must be a somewhat more useful definition, giving the receiver
> some leeway in deciding what to do with this request.

The I-bit can be used by an endpoint to indicate to its remote endpoint that it is not interested in receiving a list of locally available states. This would be indicated by setting the I-bit. 
If the I-bit is zero, it is up to the receiving endpoint to decide whether it should send a list of locally available states. 

This is the same as with the announcement information that we had in SigComp-05, except that now there is also a possibility for a compressor to say that it does not wish to receive this kind of announcement.

BR
/Hans H

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

---

From: [email-masked]
Date: Tue, 16 Apr 2002 16:24:02 -0500

> The I-bit can be used by an endpoint to indicate to its 
> remote endpoint that it is not interested in receiving a list 
> of locally available states. This would be indicated by 
> setting the I-bit. 
> If the I-bit is zero, it is up to the receiving endpoint to 
> decide whether it should send a list of locally available states. 

Just one editorial comment. Should we add specifications on
the receiver behavior as follows?

"If I-bit is set to zero, the receiving endpoint MUST NOT return 
the list of locally available state items. Otherwise, it SHOULD
return the list. "

Same comment goes to S-bit.

Zhigang

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Wed, 17 Apr 2002 09:37:56 +0200

> Same comment goes to S-bit.

I do not think it is necessary, SigComp would not crash if it receives this kind of information although it is unwanted. I think the current text should be enough motivation for not sending the list if the I-bit is set.

Section 9.4.7
"...This can help to conserve bandwidth by avoiding..."

BR
/Hans H

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 14:00:11 +0100

Hi,

The S-bit and the I-bit are both items of announcement data; they
carry some information about the capability of the sending endpoint,
which may or may not influence the behaviour of the receiving endpoint.

If the S-bit is set to 1 then the sending endpoint says the following:

"I do not wish to save any new state items at the receiving endpoint,
or to access any state items that I previously created".

The receiving endpoint can do what it likes with this information.
Typically it will set the state_memory_size of the session to 0, and
delete any state items that are no longer needed.

The sending endpoint is welcome to change its mind and switch the S-bit
back to 0 in a later message. However, the receiving endpoint is under
no obligation to use the original state_memory_size for the session; it
may choose to allocate less memory to the session or possibly none at all.

If the I-bit is set to 1 then the sending endpoint says the following:

"I do not wish to access the locally available state items of the
receiving endpoint".

See Section 3.3.3 of the draft for a definition of "locally available
state items". Based on this information the receiving endpoint will
typically stop sending the list of locally available state items (as
the list would only be discarded), but if it chooses to send the list
anyway then the only harm is a slightly reduced compression ratio.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 8:38 AM
> To: [email-masked]'; [email-masked]
> Subject: RE: [rohc] sigcomp issue lejo-10
> 
> 
> I do not think it is necessary, SigComp would not crash if it 
> receives this kind of information although it is unwanted. I 
> think the current text should be enough motivation for not 
> sending the list if the I-bit is set.
> 
> Section 9.4.7

---

From: [email-masked]
Date: Wed, 17 Apr 2002 09:57:11 -0500

> receives this kind of information although it is unwanted. 

No, it doesn't. However, should we not give the sender a
precise control on the receiver's response? Otherwise, what
is the point of I-bit ("hey, here is my request, but feel free
to ignore it)? Or what is the benefit of not specifying above?

(As in any protocol, the consequence of an information element
from a sender to a receiver should be specified clearly unless 
there is a reason to make it fuzzy.)

Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 17:22:26 +0100

> Richard,
> 
> Sorry, I failed to follow your example below. Step 1 and 2 happen 
> before the local endpoint receives the I=1 message. So it is 
> irrelevant to the behavior of a receiver of I=1, which is the 
> subject of discussion here.
> 
> Do you mean that in Step 4, the local endpoint has to keep 
> sending the list of locally available states to avoid reducing
> compression efficiency? Could you clarify further? I'm lost here.

What has happened by Step 4 is that the list of locally available
state is now stored at the remote endpoint as part of the state item
that the local endpoint wishes to access. When the state item is
accessed the list of locally available state will automatically be
copied into the UDVM memory at the returned_parameters_location.

So, how can the local endpoint avoid announcing its list of locally
available state items? It could specifically delete the list from
the UDVM memory, but this would cost additional bits in the
compressed message.

Alternatively it could avoid saving the list as part of the state
item in the first place. However, it's quite costly to precisely
specify which parts of the UDVM memory will be saved as state and
which will be discarded (it would require a lot of COPY instructions
to move all of the data that needs to be saved into a continuous
block). It's much easier to just dump the entire UDVM memory into
state.

Hope this clarifies the example!

Regards,

Richard

> > Here's a (fairly) plausible situation where it is useful to
> > announce a list of locally available state, even though the
> > remote endpoint has indicated that it doesn't need one:
> > 
> > 1.  An endpoint sends its list of locally available state items in
> >     the very first SigComp message of the session.
> > 
> > 2.  The endpoint creates a new state item at the remote endpoint,
> >     which (for simplicity) contains the entire contents of the
> >     UDVM memory including the list of locally available state.
> > 
> > 3.  The remote endpoint returns a message with the I-bit set to 1,
> >     indicating that it doesn't need the locally available state
> >     after all.
> > 
> > 4.  The local endpoint sends a new SigComp message, compressed
> >     relative to the state item it just created.
> > 
> > In this situation it would actually reduce the compression efficiency
> > to stop the list of locally available state from being announced. As
> > it doesn't do any harm to announce the list (even if it will just be
> > thrown away), the local endpoint can choose to keep announcing the
> > list anyway.
> > 
> > However, if the I-bit arrives before the list of locally available
> > state is sent then the compressor won't bother to send it at all.
> > This may save quite a bit of bandwidth if the list is long, which is
> > why I believe the I-bit to be useful.
> > 
> > Regards,
> > 
> > Richard
> > 
>

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 16:30:23 +0100

Hi,

Regards,

Richard

---

From: [email-masked]
Date: Wed, 17 Apr 2002 11:27:50 -0500

Thanks for the explanation, Richard. From what you describe
below, S-bit is slightly different from I-bit. Let me know
if following understanding is correct:

- S-bit is basically a "memory release" announcement. We don't
need to specify receiver's behavior (in this regard, what
I said before is wrong).

- However, you described below what the *sender" of S=1
MUST NOT expect if it switches S back to 0. This is not
in current draft. Do we have a synchronization problem here?
I'm concerned about the switch back and forth of S bit.

- I-bit. If I understand correctly, the purpose of I-bit
is to avoid overhead in feedback from remote endpoint.
Then, what is wrong to specify the receiver's behavior
accordingly? (still need to understand your example in the 
other email).

Zhigang

> From: ext Price, Richard [mailto:[email-masked]]
> Sent: April 17, 2002 8:00 AM
> To: 'Hans Hannu (EPL)'; Liu Zhigang.C (NRC/Dallas); [email-masked]

---

From: [email-masked]
Date: Wed, 17 Apr 2002 11:00:15 -0500

Richard,

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 17 Apr 2002 15:00:46 -0500

Richard,

Now that I understand your example, it's clear to me you're
talking about something different. Correct me if I'm wrong,
there is no bytes *transmitted* on the wire (or wireless)
in step 4, right?

However, the issue here is about setting I-bit to 1 "to conserve 
bandwidth by avoiding the transmission of feedback data ...".
I think the confusion is caused by the ambiguity of word "return"
which I used in my proposal. How about the following text?

"If I-bit is set to zero, the receiving endpoint SHOULD stop
transmitting the list of locally available state items to the
sending endpoint. Otherwise, it SHOULD transmit the list. "

(Note that I also changed MUST to SHOULD according to Hans' 
point, i.e., it will not cause a failure of the sender if the 
receiver does not follow above text.)

Zhigang

> Sent: April 17, 2002 11:22 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked];
> [email-masked]

---

From: [email-masked]
Date: Wed, 17 Apr 2002 15:24:29 -0500

Sorry, a typo in my text (zero should be 1), it should read:

"If I-bit is set to 1, the receiving endpoint SHOULD stop
transmitting the list of locally available state items to the
sending endpoint. Otherwise, it SHOULD transmit the list."

Zhigang

> From: Liu Zhigang.C (NRC/Dallas) 
> Sent: April 17, 2002 3:01 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 18 Apr 2002 12:53:40 +0100

> there is no bytes *transmitted* on the wire (or wireless)

Right.

> which I used in my proposal.

Yes, the weasel word "return" caused the confusion on this issue.
Thanks to the presence of state information we have to distinguish
between the data transmitted from the compressor to the UDVM, and
the data forwarded from the UDVM to the state handler (which may
either be uploaded or accessed from a state item).

Since we wish to avoid the *transmission* of unnecessary feedback
data, we need to make a recommendation on the behaviour of the
compressor (Chapter 5 in the base SigComp draft).

In fact we already have the following text on the subject:

"The compressor SHOULD also upload the local SigComp parameters
to the remote endpoint, unless the endpoint has indicated that
it does not wish to receive these parameters or the compressor
determines that the parameters have already successfully arrived."

> How about the following text?
> 

This text is along the lines of the text we currently have, but in
more detail as it refers specifically to the I-bit. We should
certainly add some more detail if the current text is confusing.
However we should also make sure to mention the S-bit as well,
since this behaves in a similar manner to the I-bit (the compressor
sends the state_memory_size unless the S-bit is set to 1, in which
case it doesn't send the state_memory_size to save bandwidth).

> receiver does not follow above text.)

The text we currently have on this issue also uses a SHOULD for
the same reason.

Regards,

Richard

---

From: [email-masked]
Date: Thu, 18 Apr 2002 12:58:33 -0500

> certainly add some more detail if the current text is confusing.

To make implementers' life easier, I suggest to make the text in 9.4.7 
(redundantly) clear. The current text uses "returned" which is confusing 
just as we saw. Also, we can add explicit reference to I-bit in section 5.

> case it doesn't send the state_memory_size to save bandwidth).

It's not entirely clear to me about the function of S-bit. But I'll
discuss that in cabo-15 (zliu-1). Here, a question about transmission
of state_memory_size: is it transmitted as part of "returned feedback
item" in Figure 3 or as part of "remaining SigComp message"? I guess
the answer is the latter. Then that means you can upload the value
of state_memory_size in your custom format. If this is correct, we
should:

1) add text to clarify this in 9.4.7, i.e. The format of Figure 13 is 
only for *local* presentation of parameters on the interface between 
UDVM and state handler, NOT a format for transmission between two 
endpoints.

2) add text in section 3.3.1 indicating the encoding format is only
for Figure 13.

This leads to my next question: what is the purpose of "returned feedback
item" then? Specifically, I'm confused by the following text in 7.1.
How does a state handler make use of it? Probably there is something
not spelled out in the draft.

"The returned feedback item is not copied to the UDVM memory; instead
it is buffered until the UDVM has successfully decompressed the
SigComp message. It is then forwarded to the state handler with the
rest of the feedback data (see Section 9.4.7 for further details)."

BR,
Zhigang

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Mon, 22 Apr 2002 23:24:31 +0200

Hi,

In an attempt to close this issue I have the following thinking,

Proposed action: Clarify sender behaviour if S-bit is switched back to zero.

-The text of Section 9.4.7 should be update in the direction according to comments to the list:

"The sending endpoint is welcome to change its mind and switch the S-bit
back to 0 in a later message. However, the receiving endpoint is under
no obligation to use the original state_memory_size for the session; it
may choose to allocate less memory to the session or possibly none at all.

Note: The format of Figure 13 is 
only for *local* presentation of parameters on the interface between 
UDVM and state handler, NOT a format for transmission between two 
endpoints."

BR
/Hans H