Subject: [sipcore] RFC4244bis - size of responses

From: "Elwell, John" <[email-masked]>
Date: Fri, 3 Sep 2010 09:13:08 +0200

The History-Info header field can get quite lengthy where a request has undergone a great deal of branching and retargeting. The entire accumulated set of hi-entries is reflected in the response. Thus a response can be considerably larger than a request from an H-I point of view, although other material in the request and not in the response might negate this. It does mean, however, that H-I can take some responsibility for a response being considerably larger overall than a request in some circumstances, particularly on the earlier hops (not on the final hop, of course). If an earlier hop has a low MTU size, this could cause a problem with UDP. Existing RFC 3261 guidance on maximum request sizes to be sent over UDP (200 bytes below maximum MTU size) might not be sufficient to cover this.

At present the inclusion of H-I in a response is subject to the option tag being placed by the UAC in the Supported header field. However, the need for this is being challenged in another thread, so it could be that H-I will be unconditionally reflected in the response. In any case, a UAC will not know about MTU sizes on downstream links, so this the option tag is not a solution to the response size problem.

What are the possible solutions?
- Override the RFC 3261 guidance on maximum request size for sending over UDP by specifying a larger contingency, sufficient to accommodate most H-I response scenarios.
- Specify that TCP is to be used when H-I is used.
- Specify that H-I should be dropped from a response to be sent over UDP if it would cause the response to exceed the maximum MTU size.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Sep 2010 03:29:12 -0400

> - Specify that H-I should be dropped from a response to be sent over UDP if it would cause the response to exceed the maximum MTU size.
You missed one:
- Not put H-I in any responses

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 3 Sep 2010 10:17:37 +0200

Yes, that is certainly another option.

John 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 03 September 2010 08:29
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sipcore] RFC4244bis - size of responses
> 
> 
> > The History-Info header field can get quite lengthy where a 
> request has undergone a great deal of branching and 
> retargeting. The entire accumulated set of hi-entries is 
> reflected in the response. Thus a response can be 
> considerably larger than a request from an H-I point of view, 
> although other material in the request and not in the 
> response might negate this. It does mean, however, that H-I 
> can take some responsibility for a response being 
> considerably larger overall than a request in some 
> circumstances, particularly on the earlier hops (not on the 
> final hop, of course). If an earlier hop has a low MTU size, 
> this could cause a problem with UDP. Existing RFC 3261 
> guidance on maximum request sizes to be sent over UDP (200 
> bytes below maximum MTU size) might not be sufficient to cover this.
> > 
> > At present the inclusion of H-I in a response is subject to 
> the option tag being placed by the UAC in the Supported 
> header field. However, the need for this is being challenged 
> in another thread, so it could be that H-I will be 
> unconditionally reflected in the response. In any case, a UAC 
> will not know about MTU sizes on downstream links, so this 
> the option tag is not a solution to the response size problem.
> > 
> > - Override the RFC 3261 guidance on maximum request size 
> for sending over UDP by specifying a larger contingency, 
> sufficient to accommodate most H-I response scenarios.
> > - Specify that H-I should be dropped from a response to be 
> sent over UDP if it would cause the response to exceed the 
> maximum MTU size.
> You missed one:

---

From: Shida Schubert <[email-masked]>
Date: Fri, 3 Sep 2010 23:22:44 +0900

I think "not put in response" is probably the 
best option and if we want to keep the semantics 
of option tag in supported for hist-info, then we 
should probably change the MUST to SHOULD 
with "unless" statement mentioning the message 
size. 

 Regards
  Shida

On Sep 3, 2010, at 5:17 PM, Elwell, John wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 3 Sep 2010 11:07:37 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]

One choice would be to just ignore the problem, since UDP datagrams can be fragmented.  As long as the response is less than 64k, it can be sent, just not efficiently.

Another choice would be to worry only about the responses back to the UAC, which is where most of the trouble is likely to occur.  (I assume that proxies are likely to be configured to prefer TCP for congestion control purposes.)  If we institute the rule "If a response has one Via and 'Supported: histinfo' is not present, the H-I header is not to be used in it." then we avoid oversized responses in this one case and are guaranteed(!) that no device that can use H-I does not see it.  I suppose we would want to add that any UAC that sends "Supported: histinfo" should send the request via TCP.

Dale