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

[zhigang.c.liu@nokia.com]

Hi Mark,

> However, we believe that we also need to define at least some 
> classes of application behaviour (i.e. how to use DAP) in 
> order to perform useful, repeatable tests.  

I'm not sure it is necessary, but certainly helpful for people who
cannot make up their own mind on how to use DAP.

> From one of 
> Zhigang's comments, you seem to be suggesting documenting the 
> application behaviour as part of the test description, and 
> that makes sense to me.  

Great, at least you agree with me. It's like the distinction
between a document defining a script language and another document
defines a sets of "meaningful" scripts written in the language. 
Another practical reason is that I don't have much bandwith for this.
 
> When you talk about B setting need-response to TRUE to 'do 
> its own test', it sounds like we have 2 tests running in 
> parallel here, and I'm not sure that's a good idea...

It is more challenging than the scenario where A is active
but B only responds passively. On the other hand, it is part 
of what should be tested, since an sigcomp implementation 
should be able to handle both incoming and outgoing messages anyway.

In practice, one can deal with the response request by returning
a dummy DAP message with empty message-body, or put the received
message in the message-body. It's easy and should not interrupt the 
"normal" tests it want to conduct. But I may miss some particular 
scenarios.

> Apologies -- the point is slightly unclear.  The scenario is, 
> in more detail:
> 	A sends message to B, requesting response
> 	B responds to A with a message that fails authentication
> 
> A is 'in charge', but B needs to know that it should respond 
> (in this case) with a message that will fail authentication.  
> Nothing in A's message will tell it this.

You're right, this particular case is not supported by current DAP. 
We can add the support (e.g. sender has more control over the 
response) in the next version. For now, A can "locally"
reject the message even though B asked A to accept.

> This test requires A to send several messages to B without 
> requesting a response, and then sends a message that does 
> request a response.  This clearly requires the sender to be 
> in control.

I think this is supported by current DAP, i.e, the sender
has full control over the need-response field of every message
it sends.

> I think that this raises an important distinction.  We are 
> *not* defining sigcomp behaviour, we *are* defining the 
> behaviour of the application that uses sigcomp.  And I think 
> that, as I said earlier, we need to define the range of 
> behaviours that are useful in order to carry out a reasonable 
> set of tests.

I'm still confused about the "range" and "reasonable set" of DAP
application behaviors. We have a set of sigcomp operations/features
we want to test. So, everyone just bring their DAP application
that targets at testing those sigcomp features (hopefully complete).
The application behaviors may be different. But that is OK. In
fact, it is even better for the interop test since that means 
a sigcomp implementation is subject to more diversified conditions.

That being said, I do agree that documentation of the some *example*
behaviors of DAP application is useful. That can serve as a starting 
point, but not as a boundary. We can populate the document as we go.

> I'm not convinced that this is necessarily true.  The 
> contents of a message may affect not only the compression 
> ratio but also have an effect on the state management 
> function at both ends. (snip)  I probably 
> need to think of a concrete example, though!

Yes, an example would help. I could miss things, given such a short time.

Zhigang
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc