Subject: [Sip] comment on draft-ietf-sip-congestsafe-00: PMTU

From: [email-masked]
Date: Fri, 9 Aug 2002 15:18:00 +0530

Hi,

The draft does not seem to explicitely address the situation of PMTU(Path
MTU) changing. If it is supposed to be implicetely addressed by having a
proxy return the current PMTU in "Proxy-Max-Size" header field in the 513
response, then the case of PMTU decreasing seems to be addressed.

i.e, if the new PMTU(as discovered by the proxy) for a path is lower then
the current PMTU, a new request destined for the same path will be
responded with a 513 response with "Proxy-Max-Size" field having a lower
value than the last. The UA will therefore get to know the new lower PMTU
and may reject requests exceeding that limit.
However for a case when the new PMTU is greater, there is no way, in the
proposed mechanism, for the UA to know the new PMTU. One might argue that
since the draft aims primarily at avoiding congestion, UA getting to know a
greater PMTU does not contribute to  congestion avoidance, but to improved
utilization. However if the UA rejects requests based on the PMTU, then in
this case, the UAC would be rejecting requests when  may actually pass
unfragmented due to an increase in the PMTU.

So, at the least, a note should be added at the end of section  5.3 to
state that the PMTU of the path in question may also increase and the
proposed mechanism does not enable for the increase to be conveyed back to
the UAC.

regards
Harsh Bhondwe
Hughes Software Systems

This message is proprietary to Hughes Software Systems Limited (HSS) and is
intended solely for the use of the individual to whom it is addressed.  It
may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.  If
you have received this message in error, please notify the originator
immediately.  If you are not the intended recipient, you are notified that
you are strictly prohibited from using, copying, altering, or disclosing
the contents of this message.  HSS accepts no responsibility for loss or
damage arising from the use of the information transmitted by this email
including damage from virus.

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Fri, 9 Aug 2002 10:36:40 -0500

> MTU) changing. If it is supposed to be implicetely addressed 
> by having a proxy return the current PMTU in "Proxy-Max-Size" 
> header field in the 513 response, then the case of PMTU 
> decreasing seems to be addressed.
> 
> i.e, if the new PMTU(as discovered by the proxy) for a path 
> is lower then the current PMTU, a new request destined for 
> the same path will be responded with a 513 response with 
> "Proxy-Max-Size" field having a lower value than the last. 
> The UA will therefore get to know the new lower PMTU and may 
> reject requests exceeding that limit. However for a case when 
> the new PMTU is greater, there is no way, in the proposed 
> mechanism, for the UA to know the new PMTU. One might argue 
> that since the draft aims primarily at avoiding congestion, 
> UA getting to know a greater PMTU does not contribute to  
> congestion avoidance, but to improved utilization. However if 
> the UA rejects requests based on the PMTU, then in this case, 
> the UAC would be rejecting requests when  may actually pass 

Yeah. You're right (although the draft is about PROXIES rejecting
requests, not UASs). If we go down this route, people are going to
insist on reinventing every bit of the windowing protocol from TCP on
top of SIP/UDP. I don't believe that's really acceptable. 

One alternative is to have a minimal mechanism that preserves congestion
safety for the holdouts that insist on using UDP. That's what the
authors were trying to do with this draft. Maybe it's not the right way
to go?

What if we just go ahead and deprecate UDP and everything to do with it
from SIP? Migual Garcia (who is involved in 3G) has argued that since
3261 made TCP support mandatory (any compliant SIP node MUST support
TCP), that deprecating UDP would be "backward compatible" with 3261.

> So, at the least, a note should be added at the end of 
> section  5.3 to state that the PMTU of the path in question 
> may also increase and the proposed mechanism does not enable 
> for the increase to be conveyed back to the UAC.

The previous seems like a reasonable suggestion for improving the
existing draft, and I propose to incorporate it.

--
Dean