Subject: [Sip] Re: [Simple] UDP - what if response is bigger than 1500 bytes (ethernet MTU)?

From: Thomas Froment <[email-masked]>
Date: Wed, 19 Jul 2006 15:31:18 +0200

[email-masked] wrote:
> Hello, 
>
> Could someone help me with following problem? 
>
> I am not sure what should be done when the response to SIP request sent
> over UDP is bigger than 1500 bytes? It can happen e.g. when PUBBLISH
> request is responded by 415 Unsupported Media Type and Accept,
> Accept-Encoding and Accept-Language headers are added.
>   

This is a good question: I think it was mentionned in last SIP WG IETF 
meeting that having responses greater than path MTU  (-200 bytes)
in SIP was not currently well specified. It was an open issue on 
draft-ietf-sip-hop-limit-diagnostics-03.txt which raises this problem
since it leads naturally to send big SIP responses.
SIP WG people may probably answer you if something is planned to handle 
this problem...
Thomas
> Thank you, 
> Silvestr Peknik
>
> Extract from RFC3261:
> 18.1.1 Sending requests:
> ...
> 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.
>
>       The 200 byte "buffer" between the message size and the MTU
>       accommodates the fact that the response in SIP can be larger than
>       the request.  This happens due to the addition of Record-Route
>       header field values to the responses to INVITE, for example.  With
>       the extra buffer, the response can be about 170 bytes larger than
>       the request, and still not be fragmented on IPv4 (about 30 bytes
>       is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
>       path MTU is not known, based on the assumption of a 1500 byte
>       Ethernet MTU.
> ... 
>
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
>
>   

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 19 Jul 2006 17:46:10 -0500

> SIP WG people may probably answer you if something is planned to handle 

This remains a problem; I have had a quick chat with Scott
Lawrence on it and we'll be submitting a draft latter part
of next week on one way to deal with this.

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Aki Niemi <[email-masked]>
Date: Fri, 28 Jul 2006 10:35:52 +0300

> of next week on one way to deal with this.

I'm curious, can that draft really suggest anything other than simply
"MUST NOT use UDP"?

Cheers,
Aki

-- 
Aki Niemi
Nokia Research Center

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 28 Jul 2006 03:02:11 -0500

Hi,

   I have been earlier proposing to deprecate the SIP over UDP and there
have been arguments about the large SDP etc.

   It will be useful for Page Mode IM, where we will be sending short
IM. Hence we might need DTLS too. Should we still deprecate it..

  Rajnish was arguing that one can cut and paste long text in the body
too. If it is so, then client can use TCP or TLS based on the size.

Thx
Samir