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

From: [email-masked]
Date: Mon, 3 Feb 2003 15:08:03 -0600

Hi,

Here is version 1c. Based on comments from Zacco and Abbie, I added 
clarifications on returned uncompressed DAP messages and "need-feedback"
header field. 

As planned, I would like to freeze this as the DAP version 1 for now.
At least it's good enough for the first SigComp interop. 

(Of course, any questions related to the understanding of the document
are still welcome. I've been trying to be concise, but may not have
covered every fine details ...)

Thanks for Abbie, Adam and Zacco for their valuable comments.

BR,
Zhigang

---

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 4 Feb 2003 15:35:52 -0000

Hi Zhigang, all,

Thanks for your hard work on DAP.  I think we have a good interoperable protocol.  I have a couple of questions about its behaviour though.

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.

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

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

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

Any thoughts/comments welcome.

Best regards,

Abbie

>Thanks for Abbie, Adam and Zacco for their valuable comments.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Tue, 4 Feb 2003 15:18:25 -0600

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:

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 5 Feb 2003 14:54:56 -0000

Hi Zhigang

>various test cases to fully test the interoperability of SigComp.

I think then that we need to look at some test cases in more detail to see how we would need to use DAP.

The test document says:
"   This test should check that Endpoint 1 can request a feedback item to be returned by Endpoint 2, and that it can make use of the returned feedback to
   improve the overall compression ratio (e.g. by accessing states acknowledged by the returned feedback).

   Support required at Endpoint 1: Uploading bytecode that requests a feedback item to be returned, and making use of the resulting feedback.
   Support required at Endpoint 2: Basic SigComp only.
"
How exactly should we test this?

Obviously the most basic test is a sequence of messages where A requests a feedback in Sigcomp and a response in DAP.  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?

There are several other possible tests:

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.

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.

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?

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.

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"

My second point was as a result of thinking about tests at this level:

If A and B are exchanging messages between 2 compartments (and A sends the first message for both) does it matter, in any test case, what is in the body of the messages returned.  If it doesn't then that's fine.  If it does then B needs some way of knowing which of the messages it has corresponds to which compartment.

e.g.

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.

The only case I can think of where it might matter is shared mode?  Is this the case and are there any others, or can all the responses be arbitrary? 

I hope this clarifies the points I was trying to raise.

Best regards,

Abbie

---

From: [email-masked]
Date: Wed, 5 Feb 2003 11:06:44 -0600

Hi Abbie,

You've raised many valid questions any person going to the interop
will have to answer. But it seems to me they are beyond the scope
of DAP. It's just a dummy protocol. :-) 

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.

Detailed answers inline.

Zhigang

> Obviously the most basic test is a sequence of messages where 
> A requests a feedback in Sigcomp and a response in DAP.  

Yes.

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

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

Both are interesting cases.

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

> 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.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Wed, 5 Feb 2003 17:33:43 -0000

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.

> and perform operations as the sender instructed. But it is the 

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..! ;-)

> Basically, each sender takes care of its own business and asks 

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

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

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

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

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

> itself. Probably something can be added to the test case document

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.

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

> the response. But there may be. We can always update the DAP when

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

---

From: [email-masked]
Date: Wed, 5 Feb 2003 19:14:13 -0600

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.

> 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

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Thu, 6 Feb 2003 02:34:58 -0000

Hi Zhigang, all,

I've commented inline, but the key point that you are raising seems to be that the sender should be in complete control of the test that it is running.  This appears to be manageable, but we should obviously agree that this is the case.

Up to now we have been assuming that there is some 'co-operative' element between the 2 enpoints in running a test.  Clearly we will have some difficulties in running tests if this is not a valid assumption!

Cheers,

Mark.

> Another practical reason is that I don't have much bandwith for this.

Of course I agree ;-)
And your analogy is helpful.  I don't think that you need commit bandwidth to this: DAP is agreed.  I'm only thinking about how we use it...
 
> should be able to handle both incoming and outgoing messages anyway.

That's a good point.

> "normal" tests it want to conduct. But I may miss some particular 

True -- ok, we should cover this in at least some of the test cases.

> reject the message even though B asked A to accept.

Hmmm -- this is certainly an example of where it's necessary to describe application layer behaviour!  It's not necessarily something that has to be supported by DAP.  However, you raise an interesting point.

If we assume that the sender is completely in control of the test, then I'm not sure that 'response' messages need to contain the authentication details, for example, since the 'controlling' endpoint (A, in this example) knows what it should do for each message that it receives in response to a message that it has sent.

> has full control over the need-response field of every message

Agreed.

> point, but not as a boundary. We can populate the document as we go.

I think I basically agree that arbitrary application behaviour is worthwhile testing.  However, the only reason I suggest documenting something (as you say -- 'example' behaviours) is to give us a baseline set of repeatable tests that we all agree on.  That doesn't mean that we cannot/should not test other things.  I agree!

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

Still haven't thought of one, but I'll see if I can..!

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Thu, 6 Feb 2003 12:25:36 +0100

Hi,

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.

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?

BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 06, 2003 2:14 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop

Hi Mark,

 

Zhigang

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 6 Feb 2003 14:51:53 -0000

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

---

From: [email-masked]
Date: Thu, 6 Feb 2003 13:45:29 -0600

Hi Mark and all,

It looks we are pretty much in agreement. Due to my
bandwidth constraints, I suggest we divide the work as follows:

- You guys will go ahead with the example test cases using DAP.
- During that process and interop tests, we probably will 
discover cases where DAP needs to modified/enhanced (e.g. more
instructions from sender to receiver). I can then take care of 
updating DAP with new versions.

BR,
Zhigang

---

From: [email-masked]
Date: Thu, 6 Feb 2003 14:01:40 -0600

Hi Zacco,

It seems you may be confused between a DAP message and its
message-body. Just in case, it is the entire DAP message 
(header + CRLF + [body]) that goes through SigComp layer 
(both the sending side and the receving side).

Detailed answer below.

Zhigang

> endpoint B? 

It knows if it doesn't receive the uncompressed message retured
from B. Of course, this assumes we don't drop the returned message.

> Empty message is not good for this purpose, as it 

There is no empty DAP message, only DAP message with empty 
message-body. The message-header is alwasy carried in each DAP message.
See above.

> header, what length should I use, the original (compressed) 
> or the actual (uncompressed) message length?

The DAP receiver simply takes whatever is delivered by the local
SigComp decompressor, check its format and then return it back 
without any modifications and without going through the local 
sigcomp compressor.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Thu, 6 Feb 2003 22:26:03 -0000

Zhigang,

This seems like an effective use of resources!

Glad to see we're converging on an answer... ;-)
(And that we definitely have enough to do for the interop)

Cheers,

Mark.

> Sent: 06 February 2003 19:45
> To: West, Mark (ITN); Surtees, Abigail; [email-masked]

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Fri, 7 Feb 2003 10:07:24 +0100

Hi,

No, I'm not confused about what to send. The fact is that some parts are simply not clear enough. See my inline comments below!
 
BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 06, 2003 9:02 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop

Hi Zacco,

Detailed answer below.

Zhigang

[L.Z.] Explicit notification would be better for testing.We could do it very simply in the verification message that is always sent back.

[L.Z.] You misunderstood me. I wanted to say: an empty string output of the UDVM did't mean decompression failure. Of course, it didn't. But it's useless to build a timeout mechanism to check decompression failure, when we have the possibility of an explicit notification. Abbie, this explicit notificatrion is nothing to do with NACK, as it is not part of SigComp but DAP.

[L.Z.] I asked something else. Abbie had an answer that I already knew: it didn't matter. I expected DAP a simple protocol without having optional things in it. For testing, it would have been favourable. I fear we have to spend long hours with adjusting our DAP versions because of the freedom DAP allows.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 7 Feb 2003 12:46:08 -0000

Hi Zacco,

Comments in-line (hopefully we're not getting too indented).

Best regards,

Abbie
>[L.Z.] Explicit notification would be better for testing.We 
>could do it very simply in the verification message that is 
>always sent back.
>
>[L.Z.] You misunderstood me. I wanted to say: an empty string 
>output of the UDVM did't mean decompression failure. Of 
>course, it didn't. But it's useless to build a timeout 
>mechanism to check decompression failure, when we have the 
>possibility of an explicit notification. Abbie, this explicit 
>notificatrion is nothing to do with NACK, as it is not part of 
>SigComp but DAP.
>
[A.S.] I think we are getting confused between empty messages and DECOMPRESSION_FAILURES occurring in the torture tests and those occurring during interoperation between 2 endpoints.
In the first case we are not using DAP and these occurrences are either expected (in which case it's fine) or they're not (in which case the implementer has something to debug).  In the second case (which is where we will be at SIPit) there are, as Zhigang said, no empty messages because there will always be a DAP header and if there is DECOMPRESSION_FAILURE then (assuming no dropped packets) there is a bug at one endpoint or the other, at which point both implementers need to look at their log files and work out what has gone wrong.

From my experience at 3095 interop tests I would say that endpoint A doesn't need to be told there has been a DECOMPRESSION_FAILURE.  I would expect that the decompressing endpoint would flag up a DECOMPRESSION_FAILURE to the implementer either in an on-screen message or in a log file.  If it's the former then the implementer will spot it and the test can be stopped and debugged or if it's the latter then test may go slightly awry but this will be noted by one end or the other and it can be debugged.  As both implementers will be present there can be discussions rather than requiring one endpoint to indicate everything to the other.
>[L.Z.] I asked something else. Abbie had an answer that I 
>already knew: it didn't matter. I expected DAP a simple 
>protocol without having optional things in it. For testing, it 
>would have been favourable. I fear we have to spend long hours 
>with adjusting our DAP versions because of the freedom DAP allows.
>
[A.S.]  I'm not sure I understand the question.  There aren't any options in DAP.  The length is always the uncompressed length because the DAP header is part of what gets compressed (in the sending direction) and the message is just returned "as is" in the uncompressed direction.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Fri, 7 Feb 2003 14:05:44 +0100

Hi,

Regarding decomp failure:

In negative tests I may send such messages _on purpose_. This is the case in several of the torture tests. For automatic test suits that can be run without any user intervention, it is essential to have all the information to set  verdict without having a look at the other implementation's log file or consulting its owner.

Regarding length I quote what you wrote:

"As there is no new DAP header being added there is no need to worry about what length to give it."
I don't think that "The length is always the uncompressed length" especially when sending the compressed message. I guess you did not mean this.

BR/Zacco

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Friday, February 07, 2003 1:46 PM
To: 'Lajos Zaccomer (ETH)'; [email-masked]'; West, Mark (ITN); [email-masked]
Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop

Hi Zacco,

Best regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 7 Feb 2003 13:40:42 -0000

Hi Zacco,

>In negative tests I may send such messages _on purpose_. This 
>is the case in several of the torture tests. For automatic 
>test suits that can be run without any user intervention, it 
>is essential to have all the information to set  verdict 
>without having a look at the other implementation's log file 
>or consulting its owner.

I agree that the torture tests can quite legitimately produce decompression failure.  However, these don't run with DAP, they are stand alone messages.  

When we are running with DAP (assuming no corruption or packet loss) there shouldn't be any decompression failure.  Why do we need to run without any intervention?  The implementers are all going to be at SIPit.
As we said before, we can extend DAP in the future if we want to, but we have enough for the interop tests which are fast approaching, so we should freeze DAP in order to implement it.

>I don't think that "The length is always the uncompressed 
>length" especially when sending the compressed message. I 
>guess you did not mean this.
>
I'm afraid I still don't understand the question you are asking. 

The diagram below shows how I see things working (correct me if I'm wrong) and there is know need to know about the length to give the returned uncompressed header.

(I am assuming that endpoint A has a body_msg of length x already known from somewhere (e.g. file))

Endpoint A

 				overall msg			overall length

                        <----x-------> 
				|body_msg    |            	x

DAP layer: adds a DAP header (length y) with line 8: "body-length: x"

			<--y--><-------x--->
			|DAP	|body_msg    |           	x + y

Sigcomp layer: compresses (x+y) bytes to z bytes

			        <------z---->
			        |Sigcomp msg| 			z

z bytes are sent to endpoint B.

endpoint B:
	 		        <------z---->
			        |Sigcomp msg| 			z

Sigcomp layer: decompresses z bytes to (x + y) bytes

			<--y--><-------x--->
			|DAP	|body_msg    |           	x + y

DAP layer: reads and verifies DAP header (length y) with line 8: "body-length: x"
		returns the (x + y) bytes it received uncompressed to endpoint A.

			<--y--><-------x--->
			|DAP	|body_msg    |           	x + y

Endpoint A receives the original message it compressed.

Nowhere has the receiving endpoint had to fill in a length value.  Hence my not understanding the question.  There is nothing optional in DAP.

Best regards,

Abbie