[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] a dummy application protocol (DAP) for SigComp interop
Hi Zacco,
>I have two questions:
>
>1. How can endpoint A now if decompression failure occured on
>endpoint B? Empty message is not good for this purpose, as it
>may be a valid output. For negative tests, it is required to
>know somehow.
>
DAP states that endpoint B should return its decompressed message to A whatever the value of the authenticate field.
If there is decompression failure then there may or may not be some output but whatever it is, it isn't going to be of any use to endpoint A, so there is no point sending it.
In terms of A actually knowing with regard to the next message to compress that there has been decompression failure, it doesn't know (nor can it because SigComp doesn't have a NACK mechanism (at the moment, at any rate)).
If endpoint B has unexpected decompression failure then the results of the test won't be as expected and it is likely that there is a bug somewhere, in which case the implementers of endpoint A and B need to work out where it is.
>2. When the uncompressed message is sent back with the same
>header, what length should I use, the original (compressed) or
>the actual (uncompressed) message length?
As I understand it, a DAP message (that is header + CRLF + body) is compressed and sent.
The decompressor receives, decompresses and passes it to the application, which checks it and returns it "as is" to the endpoint from which it came (without putting a dap header on it).
The original endpoint can distinguish it from a new DAP message because it will have the endpoint's own IP address.
As there is no new DAP header being added there is no need to worry about what length to give it.
I hope that clarifies things.
Best regards,
Abbie
>
>BR/Zacco
>
>-----Original Message-----
>From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
>Sent: Thursday, February 06, 2003 2:14 AM
>To: mark.a.west@roke.co.uk; abigail.surtees@roke.co.uk; rohc@ietf.org
>Subject: RE: [rohc] a dummy application protocol (DAP) for
>SigComp interop
>
>
>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
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc