Subject: Re: [sipcore] Call for Consensus: INFO Specification and Congestion

From: Peter Musgrave <[email-masked]>
Date: Sat, 1 May 2010 06:50:43 -0400

Works for me (and happens to be what my application does).

Peter Musgrave

On Fri, Apr 30, 2010 at 5:59 PM, Adam Roach <[email-masked]> wrote:
> [as chair]
>
> During IESG review of the INFO specification, several members expressed
> concerns about the congestion properties of INFO. The draft authors and IESG
> worked together to craft text that satisfies these concerns.
>
> Since the resulting text contains normative language, we are bringing the
> proposal to the SIPCORE working group for a 2-week consensus call. Please
> comment on the following proposed text before Friday, May 14th. If you agree
> with the proposal, please send a short response indicating that fact.
>
> "10.9.  Rate and size of INFO Requests
>
>    "INFO messages differ from many other sorts of SIP messages in that
>     they carry application information, and the size and rate of the
>     INFO message is directly determined by the application. This can
>     cause application information traffic to interfere with other traffic
>     on that infrastructure, or to self-interfere when data rates become
>     too high.
>
>    "A designer of an INFO package, and the application that uses it,
>     need to consider the impact that the size and the rate of the INFO
>     messages have on the network and on other traffic, since it normally
>     cannot be ensured that INFO messages will be carried over a
>     congestion-controlled transport protocol end-to-end. Even if an
>     INFO message is sent over a such a transport protocol, a downstream
>     SIP entity might forward the message over a transport protocol that
>     does not provide congestion control.
>
>    "Therefore, an application SHOULD generally have at most one outstanding
> INFO message.
>     The guidelines in RFC3261 Section 18 MUST be followed for sending and
> receiving INFO
>     requests and responses, such as the guideline to not exceed messages
>     sizes of 1300 bytes when the path MTU is unknown. RFC5405 provides
>     additional guidelines for applications using the User Datagram
>     Protocol (UDP) that may be useful background reading."
>
> Thanks.
>
> /a
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 1 May 2010 14:32:59 +0200

"INFO package" will of course be changed to "Info Package", in order to be alligned with the terminology in the rest of the document.

Regards,

Christer
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Saturday, May 01, 2010 12:59 AM
To: SIPCORE
Subject: [sipcore] Call for Consensus: INFO Specification and Congestion

[as chair]

During IESG review of the INFO specification, several members expressed
concerns about the congestion properties of INFO. The draft authors and
IESG worked together to craft text that satisfies these concerns.

Since the resulting text contains normative language, we are bringing
the proposal to the SIPCORE working group for a 2-week consensus call.
Please comment on the following proposed text before Friday, May 14th.
If you agree with the proposal, please send a short response indicating
that fact.

     "Therefore, an application SHOULD generally have at most one
outstanding INFO message.
      The guidelines in RFC3261 Section 18 MUST be followed for sending
and receiving INFO
      requests and responses, such as the guideline to not exceed messages
      sizes of 1300 bytes when the path MTU is unknown. RFC5405 provides
      additional guidelines for applications using the User Datagram
      Protocol (UDP) that may be useful background reading."

Thanks.

/a

---

From: Brett Tate <[email-masked]>
Date: Sat, 1 May 2010 12:58:46 -0700

Within proposed section 10.9 paragraph 2, "over a such a transport" should be "over such a transport".

The following sentence from paragraph 2 potentially could be improved.  However it is likely good enough since I'm not currently motivated enough to propose alternative wording.

"The guidelines in RFC3261 Section 18 MUST be followed for sending and receiving INFO requests and responses, such as the guideline to not exceed messages sizes of 1300 bytes when the path MTU is unknown."

Concerning the above sentence... since the INFO draft is built upon RFC3261, there is little reason to indicate that the guidelines in RFC3261 Section 18 MUST be followed; the draft is not upgrading/adjusting any of the normative and non normative text from section 18.  Concerning the referenced guideline, section 18 also has an additional guideline conflicting with the reference guideline (i.e. upon failure to successfully switch away from UDP, the large request SHOULD still be sent over UDP).

Thanks,
Brett

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 2 May 2010 02:36:51 +0200

I have significant issues with the third proposed paragraph.

>      "Therefore, an application SHOULD generally have at most 
> one outstanding INFO message.

This sentence does not solve the problem of congestion, which is the ethos for adding the text. All it does is impose limitations on implementations that are unnecessary. I would claim that I can impose congestion on the network by poor design of INFO packages even without this limitation, whereas careful use of INFO with multiple overlapping sends does not cause congestion. Therefore I do not accept this sentence.

>       The guidelines in RFC3261 Section 18 MUST be followed 
> for sending and receiving INFO

The MUST here is superfluous. By all means draw our attention to the text in RFC 3261, which already contains a MUST. But if people are really going to ignore RFC 3261, then they will also ignore the MUST here. There are lots of other MUSTs in RFC 3261 it is equally important for an INFO implementation to follow, and we get nowhere by repeating them all. I would suggest that rather than the text here, you merely informatively introduce a quote from RFC 3261 of the relevant text.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Friday, April 30, 2010 10:59 PM
> To: SIPCORE
> During IESG review of the INFO specification, several members 
> expressed concerns about the congestion properties of INFO. 
> The draft authors and IESG worked together to craft text that 
> satisfies these concerns.
> 
> Since the resulting text contains normative language, we are 
> bringing the proposal to the SIPCORE working group for a 
> 2-week consensus call. 
> If you agree with the proposal, please send a short response 
> indicating that fact.
> 
>      "Therefore, an application SHOULD generally have at most 
> one outstanding INFO message.
>       The guidelines in RFC3261 Section 18 MUST be followed 
> for sending and receiving INFO

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 May 2010 09:57:50 +0200

Hi,

I am adding Lars Eggert to the discussion, since he had most issues with this in IESG.

>Within proposed section 10.9 paragraph 2, "over a such a transport" should be "over such a transport".

Correct.

>Concerning the above sentence... since the INFO draft is built upon RFC3261, there is little reason to indicate that the guidelines in RFC3261 Section 18 MUST be followed; the draft is not upgrading/adjusting any of the normative and non normative text from section 18.  
>Concerning the referenced guideline, section 18 also has an additional guideline conflicting with the reference guideline (i.e. upon failure to successfully switch away from UDP, the large request SHOULD still be sent over UDP).

Keith had similar comments, so I suggest we discuss it in that thread.

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 May 2010 10:00:14 +0200

Hi Keith,

>"Therefore, an application SHOULD generally have at most one outstanding INFO message.
>
>This sentence does not solve the problem of congestion, which is the ethos for adding the text. All it does is >impose limitations on implementations that are unnecessary. I would claim that I can impose congestion on the >network by poor design of INFO packages even without this limitation, whereas careful use of INFO with >multiple overlapping sends does not cause congestion. Therefore I do not accept this sentence.

I'll let Lars comment on this.

>>for sending and receiving INFO requests and responses, such as the guideline to not
>>exceed messages sizes of 1300 bytes when the path MTU is unknown.
>>RFC5405 provides additional guidelines for applications using the User Datagram
>The MUST here is superfluous. By all means draw our attention to the text in RFC 3261, which already 
>contains a MUST. But if people are really going to ignore RFC 3261, then they will also ignore the MUST 
>here. There are lots of other MUSTs in RFC 3261 it is equally important for an INFO implementation to 
>follow, and we get nowhere by repeating them all. I would suggest that rather than the text here, you merely 
>informatively introduce a quote from RFC 3261 of the relevant text.

Would you be ok if we change "Section 18 MUST be followed" to "Section 18 are to be followed"?

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 2 May 2010 13:57:42 +0200

> >>receiving INFO requests and responses, such as the guideline to not 
> >>RFC5405 provides additional guidelines for applications 
> using the User 
> >>Datagram Protocol (UDP) that may be useful background reading."
> >
> >The MUST here is superfluous. By all means draw our attention to the 
> >text in RFC 3261, which already contains a MUST. But if people are 
> >really going to ignore RFC 3261, then they will also ignore the MUST 
> >here. There are lots of other MUSTs in RFC 3261 it is 
> equally important 
> >for an INFO implementation to follow, and we get nowhere by 
> repeating them all. I would suggest that rather than the text 
> here, you merely informatively introduce a quote from RFC 
> 3261 of the relevant text.
> 

That at least removes the double specification of the same MUST in two documents one of which is already dependent on the other. However I would still point out that there are lots of RFC 3261 MUSTs that I could break in an INFO implementation that would cause equal impact on the network. Therefore I still consider it unnecessary.

Can I further point out however that none of this text does not belong in section 10, as section 10 is about what needs to be documented to define an INFO package, not about what the implementor actually needs to do. It actually relates to whether it was appropriate to select INFO in the first place to do the job, as if the information transfer requirements are inappropriate to the underlying transport capabilities of SIP, then INFO should not have been selected in the first place.

regards

Keith 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Sunday, May 02, 2010 9:00 AM
> To: DRAGE, Keith (Keith); Adam Roach; SIPCORE
> Cc: [email-masked]
> Subject: RE: [sipcore] Call for Consensus: INFO Specification 
> and Congestion
> 
> Hi Keith,
> 
> >This sentence does not solve the problem of congestion, 
> which is the ethos for adding the text. All it does is 
> >impose limitations on implementations that are unnecessary. 
> I would claim that I can impose congestion on the >network by 
> poor design of INFO packages even without this limitation, 
> whereas careful use of INFO with >multiple overlapping sends 
> does not cause congestion. Therefore I do not accept this sentence.
> 
> >>receiving INFO requests and responses, such as the guideline to not 
> >>RFC5405 provides additional guidelines for applications 
> using the User 
> >>Datagram Protocol (UDP) that may be useful background reading."
> >
> >The MUST here is superfluous. By all means draw our attention to the 
> >text in RFC 3261, which already contains a MUST. But if people are 
> >really going to ignore RFC 3261, then they will also ignore the MUST 
> >here. There are lots of other MUSTs in RFC 3261 it is 
> equally important 
> >for an INFO implementation to follow, and we get nowhere by 
> repeating them all. I would suggest that rather than the text 
> here, you merely informatively introduce a quote from RFC 
> 3261 of the relevant text.
> 
> >       SIP entity might forward the message over a transport 
> protocol 
> > that
> >       The guidelines in RFC3261 Section 18 MUST be followed for 
> > sending and receiving INFO

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 May 2010 15:28:39 +0200

Hi, 

>>>>RFC5405 provides additional guidelines for applications using the User
>>>here. There are lots of other MUSTs in RFC 3261 it is equally important
>>>for an INFO implementation to follow, and we get nowhere by repeating them all. 
>>>I would suggest that rather than the text here, you merely informatively 
>>>introduce a quote from RFC 3261 of the relevant text.
>> 
>That at least removes the double specification of the same 
>MUST in two documents one of which is already dependent on 
>the other. However I would still point out that there are 
>lots of RFC 3261 MUSTs that I could break in an INFO 
>implementation that would cause equal impact on the network. 
>Therefore I still consider it unnecessary.
> 
>Can I further point out however that none of this text does 
>not belong in section 10, as section 10 is about what needs 
>to be documented to define an INFO package, not about what 
>the implementor actually needs to do. It actually relates to 
>whether it was appropriate to select INFO in the first place 
>to do the job, as if the information transfer requirements 
>are inappropriate to the underlying transport capabilities of 
>SIP, then INFO should not have been selected in the first place.

So, I guess it should be somewhere in section 7.4.

Regards,

Christer

> > Subject: RE: [sipcore] Call for Consensus: INFO Specification and 
> > Congestion
> > 
> > Hi Keith,
> > 
> > I would claim that I can impose congestion on the >network by poor 
> > design of INFO packages even without this limitation, 
> whereas careful 
> > use of INFO with >multiple overlapping sends does not cause 
> > congestion. Therefore I do not accept this sentence.
> > 
> > sending and
> > repeating them all. I would suggest that rather than the text here, 
> > you merely informatively introduce a quote from RFC
> > Would you be ok if we change "Section 18 MUST be followed" 
> to "Section 
> > 18 are to be followed"?
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > >      "INFO messages differ from many other sorts of SIP 
> messages in 
> > > that
> > >       cause application information traffic to interfere 
> with other 
> > > traffic
> > >       on that infrastructure, or to self-interfere when 
> data rates 
> > > become
> > >       too high.
> > >
> > >       need to consider the impact that the size and the 
> rate of the 
> > > INFO

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 5 May 2010 15:45:21 +0200

Yes, but obviously not in the same words. It needs to be tailored as do not choose an INFO solution if you need to do this.

Keith  

> Sent: Wednesday, May 05, 2010 2:29 PM
> >>>>and receiving INFO requests and responses, such as the 
> guideline to 
> >>>>not exceed messages sizes of 1300 bytes when the path MTU 
> is unknown.
> >>>>RFC5405 provides additional guidelines for applications using the 
> >>>>User Datagram Protocol (UDP) that may be useful 
> background reading."
> >>>
> >>>here. There are lots of other MUSTs in RFC 3261 it is equally 
> >>>important for an INFO implementation to follow, and we get 
> nowhere by repeating them all.
> >>>I would suggest that rather than the text here, you merely 
> MUST in two 
> >documents one of which is already dependent on the other. However I 
> >would still point out that there are lots of RFC 3261 MUSTs that I 
> >could break in an INFO implementation that would cause equal 
> impact on 
> >the network.
> not belong 
> >in section 10, as section 10 is about what needs to be documented to 
> >define an INFO package, not about what the implementor 
> actually needs 
> >to do. It actually relates to whether it was appropriate to 
> select INFO 
> >in the first place to do the job, as if the information transfer 
> >requirements are inappropriate to the underlying transport 
> capabilities 
> >of SIP, then INFO should not have been selected in the first place.
> 
> > > I am adding Lars Eggert to the discussion, since he had 
> most issues 
> > > with this in IESG.
> > > 
> > > I would claim that I can impose congestion on the 
> >network by poor 
> > > >       messages have on the network and on other 
> traffic, since it 
> > > > normally
> > > >       requests and responses, such as the guideline to 
> not exceed 
> > > > messages

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 14:11:42 -0500

[as a participant]

Regarding the proposed text that I sent to the mailing list last week, 
there was an exchange regarding where in the document this behavior goes;

On 5/2/10 6:57 AM, DRAGE, Keith (Keith) wrote:
> ...[T]his text does not belong in section 10, as section 10 is about what needs to be documented to define an INFO package, not about what the implementor actually needs to do. It actually relates to whether it was appropriate to select INFO in the first place to do the job, as if the information transfer requirements are inappropriate to the underlying transport capabilities of SIP, then INFO should not have been selected in the first place.
>    

> Yes, but obviously not in the same words. It needs to be tailored as do not choose an INFO solution if you need to do this.

I would argue that section 7.3 already goes over this ground in terms of 
whether INFO is appropriate for a particular use case. And, in fact, 
*most* of the proposed text isn't talking about what event package 
designers should do. Some of it does, but for the most part, the text 
talks about what implementors are required to do. The document *does* 
have a section that covers this ground: section 3.

To that end, I would think we could split this into two sections. The 
part dealing with implementation issues would be a new section 3.5; the 
other would form an introduction to the existing section 10.9.

Incorporating the other suggestions made so far, then, I would propose 
the following sections for the INFO document:

> 3.5.  Rate and Size of INFO Requests
>
>      INFO messages differ from many other sorts of SIP messages in
>      that they carry application information, and the size and rate
>      of the INFO message is directly determined by the application.
>      This can cause application information traffic to interfere
>      with other traffic on that infrastructure, or to self-interfere
>      when data rates become too high.
>
>      Implementors need to consider the impact that the size and the
>      rate of the INFO messages have on the network and on other
>      traffic, since it normally cannot be ensured that INFO messages
>      will be carried over a congestion-controlled transport protocol
>      end-to-end.  Even if an INFO message is sent over such a
>      transport protocol, a downstream SIP entity might forward the
>      message over a transport protocol that does not provide
>      congestion control.
>
>      Therefore, an application SHOULD generally have at most one
>      outstanding INFO message.  Implementors are reminded to observe
>      the guidelines in RFC3261 Section 18 regarding the size of SIP
>      messages, such as the guideline to not exceed message sizes
>      of 1300 bytes when the path MTU is unknown. RFC5405 provides
>      Protocol (UDP) that may be useful background reading.
>
>
>
> 10.9 Rate of INFO Requests
>
>      A designer of an Info package needs to be mindful of the
>      potential congestion impact their application can have on both
>      the SIP network and the Internet at large.  See section 3.5
>      for a discussion of congestion-related issues.
>
>      If there is a maximum or minimum rate at which UAs can send
>      INFO requests associated with the Info Package within a dialog,
>      the Info Package specification MUST document the rate values.
>
>      If the rates can vary, the Info Package specification MAY
>      define Info Package parameters that UAs can use to indicate
>      or negotiate the rates.  Alternatively the rate information
>      can be part of the application data information associated
>      with the Info Package.

Does that sound reasonable?

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 17 May 2010 00:02:35 +0200

>      Protocol (UDP) that may be useful background reading.

I already objected to the first sentence above as I do not believe it solves the issue, and removes useful capabilities that may be desired by some applications. I CANNOT accept this sentence.

The second sentence above is an inexact extraction, and as such misleads completely. The correct quote is below:

   If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 [43] congestion controlled transport protocol, such
   as TCP. If this causes a change in the transport protocol from the
   one indicated in the top Via, the value in the top Via MUST be
   changed.  This prevents fragmentation of messages over UDP and
   provides congestion control for larger messages.  However,
   implementations MUST be able to handle messages up to the maximum
   datagram packet size.  For UDP, this size is 65,535 bytes, including
   IP and UDP headers.

Nothing about not exceeding message sizes. Only restriction is to send using a congestion controlled transport protocol if it exceeds MTU size. Therefore second sentence as currently drafted is unacceptable.

regards

Keith

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, May 13, 2010 8:12 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Adam Roach; SIPCORE; [email-masked]
> Subject: Re: [sipcore] Call for Consensus: INFO Specification 
> and Congestion
> 
> [as a participant]
> 
> Regarding the proposed text that I sent to the mailing list 
> last week, there was an exchange regarding where in the 
> document this behavior goes;
> 
> > ...[T]his text does not belong in section 10, as section 10 
> is about what needs to be documented to define an INFO 
> package, not about what the implementor actually needs to do. 
> It actually relates to whether it was appropriate to select 
> INFO in the first place to do the job, as if the information 
> transfer requirements are inappropriate to the underlying 
> transport capabilities of SIP, then INFO should not have been 
> selected in the first place.
> >    
> 
> > Yes, but obviously not in the same words. It needs to be 
> tailored as do not choose an INFO solution if you need to do this.
> >    
> 
> I would argue that section 7.3 already goes over this ground 
> in terms of whether INFO is appropriate for a particular use 
> case. And, in fact,
> *most* of the proposed text isn't talking about what event 
> package designers should do. Some of it does, but for the 
> most part, the text talks about what implementors are 
> required to do. The document *does* have a section that 
> covers this ground: section 3.
> 
> To that end, I would think we could split this into two 
> sections. The part dealing with implementation issues would 
> be a new section 3.5; the other would form an introduction to 
> the existing section 10.9.
> 
> Incorporating the other suggestions made so far, then, I 
> would propose the following sections for the INFO document:
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 May 2010 07:31:48 +0200

Hi,

I appologize that it has taken me a while to reply on this issue. I've been busy with 3GPP the last few weeks.

Note that the draft already contains section 7.3, which talks about rate and volume. Nobody has commented on that, so I assume it is ok.

My suggestion would be to:

-	Remove section 7.3
-	Add new section 7.4.1.2, that talks about rate and volume
-	New section 7.4.1.2 consists of text from old section 7.3 and the suggested new text for section 10.9.
-	Keep section 10.9 unchanged (draft version -07)

So, new section 7.4.1.2 could look like:

"7.4.1.2.  INFO Request Rate and Volume

   INFO messages differ from many other sorts of SIP messages in that

   There is no default throttling mechanism for INFO requests. Apart
   from the SIP session establishment, the number of SIP messages
   exchanged during the lifetime a normal SIP session is rather small.

   Some applications, like sending of DTMF tones, can generate a burst
   of up to 20 messages per second.  Other applications, like constant
   GPS location updates, could generate a high rate of INFO requests
   during the lifetime of the invite dialog usage.

   A designer of an INFO package, and the application that uses it,

   Furthermore, SIP messages tend to be relatively small, on the order
   of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
   exchange of bulk data beyond these limits, especially if the headers
   plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
   such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media
   plane data transport mechanisms.

   RFC5405 provides additional guidelines for applications using the 
   User Datagram Protocol (UDP) that may be useful background reading."

And, section 10.9 would look like:

"10.9.  Rate of INFO Requests

   If there is a maximum or minimum rate at which UAs can send INFO
   requests associated with the Info Package within a dialog, the Info
   Package specification MUST document the rate values.

   If the rates can vary, the Info Package specification MAY define Info
   Package parameters that UAs can use to indicate or negotiate the
   rates.  Alternatively the rate information can be part of the
   application data information associated with the Info Package."

Would people be ok with that?

Regards,

Christer

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 17. toukokuuta 2010 1:03
> To: Adam Roach
> I already objected to the first sentence above as I do not 
> believe it solves the issue, and removes useful capabilities 
> that may be desired by some applications. I CANNOT accept 
> this sentence.
> 
> The second sentence above is an inexact extraction, and as 
> such misleads completely. The correct quote is below:
> 
> Nothing about not exceeding message sizes. Only restriction 
> is to send using a congestion controlled transport protocol 
> if it exceeds MTU size. Therefore second sentence as 
> currently drafted is unacceptable.
> 
> 
> regards
> 
> Keith
>  
> 
> > Subject: Re: [sipcore] Call for Consensus: INFO Specification and 
> > Congestion
> > 
> > [as a participant]
> > 
> last week, 
> > is about what needs to be documented to define an INFO package, not 
> > about what the implementor actually needs to do.
> > It actually relates to whether it was appropriate to select INFO in 
> > the first place to do the job, as if the information transfer 
> > capabilities of SIP, then INFO should not have been selected in the 
> > first place.
> > >    
> > 
> > I would argue that section 7.3 already goes over this 
> ground in terms 
> > of whether INFO is appropriate for a particular use case. And, in 
> > fact,
> sections. The 
> > part dealing with implementation issues would be a new section 3.5; 
> > the other would form an introduction to the existing section 10.9.
> > 
> would propose

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 17 May 2010 11:27:53 +0200

I'm OK with this proposal.

Keith 

> Sent: Monday, May 17, 2010 6:32 AM
> To: DRAGE, Keith (Keith); Adam Roach
> Cc: Adam Roach; SIPCORE; [email-masked]
> I appologize that it has taken me a while to reply on this 
> issue. I've been busy with 3GPP the last few weeks.
> 
> 
> Note that the draft already contains section 7.3, which talks 
> about rate and volume. Nobody has commented on that, so I 
> assume it is ok.
> 
> -	New section 7.4.1.2 consists of text from old section 
> 7.3 and the suggested new text for section 10.9.
> define Info
> believe it 
> > solves the issue, and removes useful capabilities that may 
> be desired 
> > by some applications. I CANNOT accept this sentence.
> > 
> > The second sentence above is an inexact extraction, and as such 
> > misleads completely. The correct quote is below:
> > 
> is to send 
> > using a congestion controlled transport protocol if it exceeds MTU 
> > size. Therefore second sentence as currently drafted is 
> unacceptable.
> > 
> > 
> > regards
> > 
> > Keith
> >  
> > 
> > > there was an exchange regarding where in the document 
> this behavior 
> > > goes;
> > > 
> package, not

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 May 2010 10:54:00 -0400

Maybe this is moot because Keith has agreed to the latest proposal...

I was wondering about your objection to recommending at most one 
outstanding INFO message - because there are useful things to do with this.

In general, having multiple outstanding requests in a dialog is 
problematic. With retransmission of lost messages this can result in 
some messages being rejected due to CSeq errors. While this isn't 
necessarily fatal, and there can be a few cases where this can still 
have utility, those cases are rare.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 17 May 2010 21:59:30 +0200

If the transport protocol is used by the application protocol in a manner that can get messages out of sequence, then the application protocol needs to provide its own capabilities to resolve the issue.

So yes, when using INFO as a compelled signalling mechanism, it is reliable.

If you do not use it that way, then the application has to put in its own sequence numbers, or whatever mechanism it so desires, to achieve the same purpose. That is of course assuming that the application protocol vulnerable to dropped or out of sequence messages in the first place. 

I believe I suggested some time ago on a very early draft that we might want to put something about this in the document, but no one ever took it up. Too late now.

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, May 17, 2010 3:54 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Adam Roach; Adam Roach; SIPCORE; 
> [email-masked]
> I was wondering about your objection to recommending at most 
> one outstanding INFO message - because there are useful 
> things to do with this.
> 
> In general, having multiple outstanding requests in a dialog 
> is problematic. With retransmission of lost messages this can 
> result in some messages being rejected due to CSeq errors. 
> While this isn't necessarily fatal, and there can be a few 
> cases where this can still have utility, those cases are rare.
> 
> 	Thanks,
> 	Paul
> 
> >> I appologize that it has taken me a while to reply on this issue. 
> >> I've been busy with 3GPP the last few weeks.
> >>
> >>
> >> Note that the draft already contains section 7.3, which 
> talks about 
> >> rate and volume. Nobody has commented on that, so I assume 
> it is ok.
> >>
> protocol that
> using the 
> >>    If the rates can vary, the Info Package specification 
> MAY define 
> >> Info
> >>>    than 1300 bytes and the path MTU is unknown, the 
> request MUST be 
> >>> sent
> >>>    using an RFC 2914 [43] congestion controlled transport 
> protocol, 
> >>> such

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 May 2010 06:22:53 +0200

Hi,

>I believe I suggested some time ago on a very early draft that we might want to put something about this in the document, but no one ever took it up. Too late now.

Some text does exist in Section 3.4.

Also, I don't believe we had the restriction in the old RFC, so in the event that thera are existing implementations sending multiple outstanding INFOs, I don't want to suddenly make them non-standard compliant.

So, Lars, can you live with the text I suggested? :)

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 May 2010 08:43:56 -0500

[as participant]

> Also, I don't believe we had the restriction in the old RFC, so in the event that thera are existing implementations sending multiple outstanding INFOs, I don't want to suddenly make them non-stand…

They also don't include an Info-Package header field. No matter what you 
do, RFC 2976 implementations aren't going to be compliant to the new 
specification. Any arguments about "making RFC 2976 implementations 
non-compliant" are red herrings.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 May 2010 15:58:25 +0200

Hi,

>>Also, I don't believe we had the restriction in the old RFC, so in the event that thera are existing >>implementations sending multiple outstanding INFOs, I don't want to suddenly make them non-standard >>compliant.
>

The draft also defines the "legacy INFO usage", which means RFC 2976 implementations will continue to be compliant.

Anyway, Lars has indicated that he can live with my suggested text, so my intention is to update the draft based on that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 May 2010 09:57:12 -0400

> If the transport protocol is used by the application protocol in a manner that can get messages out of sequence, then the application protocol needs to provide its own capabilities to resolve the i…

In general there is little/nothing the application can do to ensure that 
  multiple in-flight INFO messages stay in order. Even if TCP is used on 
every hop, messages may be reordered as they transit a proxy. Hence 500 
responses due to the out of order messages may be received.

And yes, the application protocol can be designed to function in the 
face of that. I'm not suggesting that having multiple INFOs outstanding 
be forbidden - just reminding that there are more problems with using 
them than simply congestion.

> So yes, when using INFO as a compelled signalling mechanism, it is reliable.

I don't understand the above. What is a "compelled signalling mechanism"?

> I believe I suggested some time ago on a very early draft that we might want to put something about this in the document, but no one ever took it up. Too late now.

As long as we are all on the same page about this I'm satisfied.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 19 May 2010 18:52:48 +0200

A compelled signalling mechanism is one where you cannot send the next packet until you have received the ack to the previous packet, i.e. a window size of one. As such the compelling guarantees the order, and the protocol does not need sequence numbers. I believe the term was in use in telecommunication signalling systems that behaved this way.

Keith

> Sent: Wednesday, May 19, 2010 2:57 PM
> To: DRAGE, Keith (Keith)
> > If the transport protocol is used by the application
> protocol in a manner that can get messages out of sequence,
> then the application protocol needs to provide its own
> capabilities to resolve the issue.
>
>   multiple in-flight INFO messages stay in order. Even if TCP
> is used on every hop, messages may be reordered as they
> transit a proxy. Hence 500 responses due to the out of order
> messages may be received.
>
> And yes, the application protocol can be designed to function
> in the face of that. I'm not suggesting that having multiple
> INFOs outstanding be forbidden - just reminding that there
> are more problems with using them than simply congestion.
>
> > If you do not use it that way, then the application has to
> put in its own sequence numbers, or whatever mechanism it so
> desires, to achieve the same purpose. That is of course
> assuming that the application protocol vulnerable to dropped
> or out of sequence messages in the first place.
> >
> > I believe I suggested some time ago on a very early draft
> that we might want to put something about this in the
> document, but no one ever took it up. Too late now.
>
> >> outstanding INFO message - because there are useful things
> to do with
> >> this.
> >>
> >> some messages being rejected due to CSeq errors.
> >> While this isn't necessarily fatal, and there can be a few cases
> >> where this can still have utility, those cases are rare.
> >>
> >>    Thanks,
> >>    Paul
> >>
> >>>>>    If a request is within 200 bytes of the path MTU, or
> if it is
> >>>>> larger

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 19 May 2010 19:21:07 +0200

Thinking about it a bit more, maybe the term "compelled" was not the best word, as it may imply an element of continued or repeated transmission until an ack is received, which is certainly not what I meant to occur at the application level.

So I'll stick to the window size of one.

In any case I was just explaining what I meant, and none of this needs a revision of the text.

Keith

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, May 19, 2010 5:53 PM
> To: Paul Kyzivat
> A compelled signalling mechanism is one where you cannot send
> the next packet until you have received the ack to the
> previous packet, i.e. a window size of one. As such the
> compelling guarantees the order, and the protocol does not
> need sequence numbers. I believe the term was in use in
> telecommunication signalling systems that behaved this way.
>
> Keith
>
> then the
> > application protocol needs to provide its own capabilities
> to resolve
> > the issue.
> >
> >   multiple in-flight INFO messages stay in order. Even if
> TCP is used
> > on every hop, messages may be reordered as they transit a
> proxy. Hence
> > 500 responses due to the out of order messages may be received.
> >
> > face of that. I'm not suggesting that having multiple INFOs
> > outstanding be forbidden - just reminding that there are
> more problems
> > with using them than simply congestion.
> >
> > put in its own sequence numbers, or whatever mechanism it
> so desires,
> > to achieve the same purpose. That is of course assuming that the
> > application protocol vulnerable to dropped or out of
> sequence messages
> > in the first place.
> > >
> > >>>>    exchange of bulk data beyond these limits,
> especially if the
> > >>>> headers