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

From: [email-masked]
Date: Fri, 24 Jan 2003 19:03:40 -0600

Hi,

Attached is a simple protocol that can be used for the 
interop test during SIPit in February. 

Your comments are welcome.

Zhigang

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Mon, 27 Jan 2003 12:30:06 +0100

Hi,

How will we test feedback, returned parameters and extended features with DAP? It seems that the receiving node is indeed a receiver and cannot be instructed to send me anything.

Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 25, 2003 2:04 AM
To: [email-masked]
Subject: [rohc] a dummy application protocol (DAP) for SigComp interop

Hi,

Zhigang
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Mon, 27 Jan 2003 10:17:01 -0600

The receiving node is also a sending node. It can can always send a DAP
message in the reverse direction on which sigcomp signals can be piggybacked. 
But you have a good point that it should be made explicit in the DAP.
I'll send a revised version soon.

Zhigang

> From: ext Lajos Zaccomer (ETH) [mailto:[email-masked]]
> Sent: January 27, 2003 5:30 AM
> To: Liu Zhigang.C (NRC/Dallas); [email-masked]
> Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp
> interop
> 
> 
> Hi,
> 
> How will we test feedback, returned parameters and extended 
> features with DAP? It seems that the receiving node is indeed 
> a receiver and cannot be instructed to send me anything.
> 
> Zacco
>

---

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 28 Jan 2003 09:18:22 -0000

Hi, 

The DAP looks good to me.  I do have a couple of comments:

I think for that for the first version we don't need to worry about IPv6 addresses.

When the messages are returned in plain text to the compressor, do they have a DAP header on them?

I think we should keep it simple and that a true/false need response field is sufficient for the first testing event.  If we want to write a second version that is more complicated then we could do so at a later date.

Best regards,

Abbie 

>From: Adam Roach [mailto:[email-masked]]
>Sent: 28 January 2003 01:33
>To: [email-masked]; [email-masked];
>[email-masked]
>Subject: Re: [rohc] a dummy application protocol (DAP) for SigComp
>interop
>
>
><[email-masked]> writes:
>
>> - added "need-response" header field
>
>I thought we had discussed having a *counter*, not a TRUE/FALSE value.
>That way, you can avoid accidental infinite loops, *and* it 
>makes it much
>easier to run a test of, say, 4 back-and-forth messages (e.g. 
>to retrive
>state) than a simple TRUE/FALSE. Here's some text.
>
>line-7 = "hops-left" ":" 1*digit
>
>- If the header line-7 of a received DAP message is greater 
>than zero, the
>receiver will send back a response message to the sender. As mentioned
>above, the response message must be compressed by and sent from the
>local compressor compartment that is peer of the remote compressor
>compartment. Line-7 of the response message will carry the value that
>is one less than the value of line-7 from the received message.
>Other than these constraints, the response message can carry
>arbitrary message-header and message-body. For testing, the
>message-body of a response may contain the message-header
>of the original message that triggered the response.
>
>
>/a
>
>

---

From: [email-masked]
Date: Tue, 28 Jan 2003 09:50:16 -0600

Abbie,

> I think for that for the first version we don't need to worry 

OK, that's what I thought too. 
 
> When the messages are returned in plain text to the 
> compressor, do they have a DAP header on them?

Yes, the entire DAP messages (message-header + CRLF + message-body)
are returned. This allows the sender to verify exactly what it has sent.

> I think we should keep it simple and that a true/false need 
> response field is sufficient for the first testing event.  If 
> we want to write a second version that is more complicated 
> then we could do so at a later date.

I agree. 

BR,
Zhignag

---

From: [email-masked]
Date: Tue, 28 Jan 2003 10:23:12 -0600

> makes it much easier to run a test of, say, 4 back-and-forth messages (e.g. 
> to retrive state) than a simple TRUE/FALSE. Here's some text.

Adam,

I cannot recall we discussed about a counter, perhaps I missed that part.

It seems to me that counter is not necessarily better than a simple
TRUE/FALSE toggle:

- To cut an infinite loop, any of the two endpoints can set need-response
to FALSE. That is no more difficult than checking the counter value and 
then decrementing it.

- To have a 4 back-and-forth messages, an endpoint can send two messages
with need-response set to TRUE.

Also, the hop-count in the message-header seems a bit fuzzy conceptually. 
It makes perfect sense to use it in IPv4 to avoid loops of the *same* 
datagram. Here, we are not necessarily talking about the same message being 
ping-panged. To me, it makes more sense to maintain a *local* counter by a 
sender to control the number of responses it want to trigger, not in the 
message-header.

So, unless I missed something important or someone else also wants to 
have the counter, let's keep the current need-response header.

Zhigang