RE: [rohc] a dummy application protocol (DAP) for SigComp interop

[zhigang.c.liu@nokia.com]

Hi Abbie,

Please see my answers inline. 

Just one comment first. DAP is a simple tool to facilitate 
the tests of SigComp. Except some required behavior on the receiving
side, the sender's behavior is pretty much open. I.e. how to *use* 
DAP is the sender's choice. This flexibility allows us to construct 
various test cases to fully test the interoperability of SigComp.

Zhigang

> If the sender sets the need-response header field to TRUE but 
> doesn't receive anything back within a certain time, what 
> should it do?  Should it retransmit the message it just sent 
> or carry on and transmit the next one it was planning to send anyway?
> 
> I think to answer this we have to look at the test scenarios. 
>  I think the main one where the possibility of retransmission 
> may be interesting is the case of dropped packets.

I guess you are talking about SigComp over UDP. Also, you must
mean the sender does not even receive the uncompressed message. 
(Otherwise, the sender will know the message has been received). 
There are 2 possibilities: a) the message sent by the sender 
is lost; b) both the uncompressed and compressed message returned by the 
receiver are lost.

It's up to the sender to decide which case it is dealing with. If it
is "conservative", a retransmission may be a good idea especially
when the possibly lost message carries state creation request that
may be used by the next message. Or it can continue to the next one. 
It should do whatever it needs to do.

> As this is not a huge issue I think that it would be good if 
> we could configurably either retransmit or continue but that 
> continuing with the next message is simplest, and sufficient 
> if configurable isn't possible (dropped packet retransmission 
> can be dealt with by duplicate messages).

This is a local decision by the sender. Sorry, I  what you mean
by "configurable".

> A similar question is about compartments and repeatability of 
> the test.  There are several possible behaviours for an 
> endpoint sending a return message:
> - send back what it received,
> - send an arbitrary message,
> - send a specific message

The main reason to have a response message - at least for
now - is to allow piggybacked sigcomp feedback. The message-body
and some (but not all) message-header fields are not specified. However,
note the "peer compartment rule" specified in DAP. 

> If I am a receiver and I have specific messages to send to 
> separate compartments at the same remote endpoint, does it 
> matter which I send to which compartment? If it does 
> (possibly for repeatability of the test?), then can this be 
> agreed out of band e.g. configured compartment ids or must it 
> be worked out (if so, how)?

See above. If it is a response requested by the sender, you
must send the message from a local compartment that is
peer the remote compartment. Also see the DAP document.

If the receiver wants to send a message to a different 
compartment, it must send another message on its own.

> Again I think we need to look at the scenarios we want to 
> test, to see how much of an issue this is.
> I think that automatically working this out, or sending the 
> information to the receiver would require 
> changes/enhancements to DAP so I suggest that we are able to 
> configure compartment ids and exchange the information of 
> what they are verbally.

I'm not sure I understand the issue. As described in current DAP, 
the sender decides the compressor compartment ID of a message it sends.
Then the receiver will use the (endpoint-ID, compressor compartment ID)
pair to derive the corresponding decompressor compartment. Do you
mean you also want to control the local representation of the
decompressor compartment ID? Probably description of some particular
scenarios would help. I certainly agree that we can/should add whatever 
enhancements to DAP when needed.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc