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

["West, Mark (ITN)" <mark.a.west@roke.co.uk>]

Hi Zhigang, all,

Sorry for jumping in, but Abbie's finished for today, and I think it would be helpful to try and resolve this.  So, here goes...

I think that the issue is largely one of what we are describing.  DAP, as you point out, is a dummy application protocol (the name says it all!) and I believe that we have agreed on the structure of the DAP header.  So far, so good...

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.  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.  I think that there are only a few sensible behaviours that need to be considered.

Anyway, comments inline.  Hopefully the nesting isn't getting *too* confusing!

Cheers,

Mark.


> 
> The unspoken philosophy is: write your test code using DAP in the 
> best way you see, following the test cases described in the document
> Richard sent. DAP guarantees the receiver will understand the message 
> and perform operations as the sender instructed. But it is the 
> sender that leads.

That sounds like a perfectly reasonable philosophy.  And we should all agree on it, otherwise I think we'll have problems.  And I really hope that we don't end up testing our applications, instead of sigcomp..! ;-)

> 
> > If we do this with multiple messages, should B know to request a 
> > response too or will A automatically send another message on 
> > receipt of a message from B?
> 
> If B wants to do its own test and need a DAP message coming back,
> it should explicitly request so by setting need-response to TRUE.
> Basically, each sender takes care of its own business and asks 
> what it needs.

Ok, so that's applying the philosophy above.

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...

>  
> > That if a message doesn't authenticate, then any feedback 
> > received with it is ignored.  Requires the receiver to set 
> > the authenticate field to reject.
> 
> Not exactly, it is the sender that tells the receiver whether 
> a message should be accepted or rejected.

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.

> 
> > Which feedback item is sent if multiple messages request 
> > feedback but there is no return message, then eventually there is?
> > Sender must set response to false for several messages even 
> > though sending with compressor that expects feedback.
> 
> For each message received with need-response set to TRUE, the receive
> must send a DAP message back. It doesn't matter what it carries
> (the message-body can even be empty). Its purpose is only to allow
> the piggyback of sigcomp feedback.

I think another slight misunderstanding here...
The simple answer is to take your 'sender-centric' view, in which the sender controls what happens.
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.

>  
> > The message arrives but the feedback is lost.  If the sender 
> > retransmits then identical state will be created - a feature 
> > which should be tested.  If the sender continues and sends 
> > its next message new state will be created (the compressor 
> > should not reference the lost message).
> > Which are we trying to test?
> 
> Both are interesting cases.

Indeed, and so our view is that both should be tested.  However, this suggests that a DAP endpoint should be configurable to retransmit or continue after a timeout.  (You can 'fake' the retransmission case).

> 
> > The message doesn't arrive so the sender never receives any 
> > feedback.  (This could be simulated by the sender instructing 
> > the receiver to reject the message.)  Again the choice 
> > between retransmission or continuation could have an effect 
> > on the compressor.
> 
> True, just as any sigcomp implementation has to make its own choice.
> 

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 think that in order to be clear how DAP needs to behave, we 
> > have to be clear on what exactly we are trying to test and 
> > how - maybe to the level of specifying, for example,
> > "A and B exchange 6 messages with feedback" or
> > "A sends 4 messages to B, requesting a response, the 3rd 
> > being a retransmission of the second because that response is 
> > not received"
> 
> What you describe here is the sender's behaviours, not the DAP
> itself. Probably something can be added to the test case document
> sent by Richard? 

Well, it's the behaviour of the application using DAP, yes.  And that's what we are trying to describe.  Apologies if this 'layer' issue has confused things..!

If we agree that the tests should describe the application behaviour then I'm all in favour of that.

>  
> > A has msg_2a and msg_3a to send from compartments 2 and 3, 
> > both going to B and asking for a response.  B has ready 
> > prepared messages msg_2b and msg_3b to go to A.  Does it 
> > matter whether msg_2b is the response to msg_2a or msg_3a?  
> > If it does, then B must have some way of 
> distinguishing/knowing that.
> 
> For piggybacking sigcomp feedback, the message-body of a response
> doesn't matter. It's just a DAP message. Note, B must generate
> a response message if there is none "ready". That is why I put the 
> wording about encapsulating the original message in the message-body
> of the response.
>  
> > The only case I can think of where it might matter is shared 
> > mode?  
> 
> It matters only in terms of compression ratio. (Obviously if
> the response message-body contains the original message, the ratio
> will be higher.) But in terms of testing the interoperability, no.
> 

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.  Now, it may be that this isn't an issue, but I'm not absolutely convinced that the nature of the returned message is completely irrelevant.  I probably need to think of a concrete example, though!

> > Is this the case and are there any others, or can all 
> > the responses be arbitrary? 
> 
> At this moment, I don't see a need to specify the message-body of
> the response. But there may be. We can always update the DAP when
> we have a clearer view.

It's not really a DAP issue, but it is an issue for the application using DAP.  See previous comment for more rambling..!

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