[rohc] RE: DAP issues

[zhigang.c.liu@nokia.com]

Hi,

I agree pretty much with Abbie, especially the technical reasons. Let's keep this simple for the first sigcomp interop (we're running out of time). We will have time to discuss the next one after this.

As Zacco proposed, please send any other comments by end of this week. I'll be on vacation tomorrow (Friday) and but be back on Monday. Will see if any other issues pop up (I hope not).

BR,
Zhigang

> -----Original Message-----
> From: ext Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]
> Sent: January 30, 2003 11:54 AM
> To: 'Lajos Zaccomer (ETH)'; 'rohc@ietf.org'
> Cc: Liu Zhigang.C (NRC/Dallas); 'Adam Roach'
> Subject: RE: DAP issues
> 
> 
> Hi all,
> 
> >The discussions on DAP should be ended this week as the SIPit 
> >is very close. All the participants that intend using DAP 
> >should accept a last version that should be available at 
> >latest on Monday morning. The accepted version should be used 
> >by the participants of SIPit.
> 
> This sounds reasonable to me.
> 
> >
> >I have the following modification and extention proposals:
> >
> <snip - moved to bottom>
> >
> >* need-response should have values: ("ANY" / "PREV" / "NO")
> >	- ANY: implementation choice
> >	- PREV: send back the previously uncompressed message 
> >of the compartment
> >		(This is very useful for testing if the message 
> >was decompressed correctly, as the other endpoint does not 
> >know what I sent.)
> >	- NO: need no response
> >
> I think it is still defined in DAP to echo the received 
> message back to the sender, uncompressed, so there isn't any 
> need to recompress it and send it back for checking purposes. 
>  Consequently the TRUE/FALSE corresponds to ANY/NO and is 
> sufficient for our testing at the moment.  (ANY could be 
> equivalent to PREV, depending upon the configuration of the 
> decompressor)
> 
> >* the header should not be arbitrary in case of a response. It 
> >should not be allowed to ask for a response in this case. It 
> >is most favourable that the message flow may be  entirely 
> >controlled by one of the endpoints!
> >
> I think that it makes sense for the receiver not to ask for a 
> response so that the sending end is in control of the flow 
> but I don't think it needs to be specified in DAP.  The 
> receiver can just never set the response field to TRUE and 
> the sender should ignore this field.
> 
> >* parameterization of compartment create:
> >this line is processed only if line-6 brings CREATE
> >line-6a = "state-memory-size" ":" *DIGIT CRLF
> >if there is no parameter, the application on its own may 
> >choose a state memory size
> >(it might be line-7 or whatever with shifting the other lines)
> >
> >* There should be another line to start/stop the dispatcher. 
> >Reason: there are tests even amongst the torture testst that 
> >use non-default values, and it is favourable to test all 
> >possible situations.
> >
> I believe that there is only one torture test now that 
> doesn't run in 2K of memory and that it can be modified to run in 2K.
> 
> >line-x = "dispatcher-op" ":" ( "START" / "STOP" );
> >line-y = "dispatcher-params" ":" *DIGIT ":" *DIGIT ":" *DIGIT
> >(may be inserted somewhere before the body line)
> >The three parameters - each of which are optional - are the 
> >cpb, dms and sms values for the dispatcher, respectively. If 
> >any of them is not specified or invalid, the application may 
> >choose a valid value instead.
> >
> 
> I think that in both these cases there may be some merit in 
> defining them in the future but that for the moment we have 
> sufficient for a first face-to-face testing event.  
> 
> As it is defined a SigComp decompressor would not expect to 
> have to change these parameters on the fly so to do it would 
> bring extra implementation.  It would also need more 
> definition than this due to the fact that some of these are 
> endpoint actions rather than compartment actions.  If an 
> endpoint were connected to 2 peers and one sent a 
> dispatcher-op : STOP message, what would happen to the 
> connection to the other peer?...
> 
> I think (correct me if I'm wrong) that for the first testing 
> event we want a simple protocol that we can ascertain quickly 
> is doing what we expect so that we can concentrate on the 
> SigComp testing itself.  Then if we want to do more testing 
> or possibly remote testing we could define some of these 
> actions, later.
> 
> Best regards,
> 
> Abbie,
> 
> 
> >With these modifications a whole series of tests may be run 
> >automatically.
> >
> >Please, consider the above issues and comment them!
> >
> >BR/Zacco
> >
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc