RE: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01

[<Erkki.Koivusalo at nokia.com>]

Hi,

>Introduction and the Overview of Operation sections and you will see
>that this proposal does not add a lot of complexity to Outbound.

I quite much disagree and still think it is too complex. 
The draft introduces the following pattern:

1. Proxy receives such a big SIP request that it can not pass it
   to the UA via the persistent UDP flow
2. Consequently the proxy will send ForceTCP message to the UA
3. The UA will open a temporary TCP connection towards the proxy
4. The UA will send a GetToken request to the proxy over the TCP
   connection
5. The proxy will respond GetToken with a new flow token assigned
   to the TCP flow
6. UA will store this new TCP flow token and associate it with the
   UDP flow
7. UA will respond to the ForceTCP message returning the flow token
   of the TCP flow to the proxy
8. Based on the response from the UA the proxy can now re-map the
   big SIP request from UDP flow to the new TCP flow and forward
   it to the UA

That does not sound too easy to me. Especially when thinking about:
- Various interactions between the SIP and STUN stacks required
- Requirement for the UA to start opening TCP connections when
  there is no SIP request to sent (a change to the connection
  management architecture laid out in RFC 3261).
- Usage of SigComp together with SIP and STUN muxed over a 
  TCP connection, if the deployment requires using SigComp

I believe the proposed mechanism does not clearly describe to 
which address and port the UA should set up its TCP connection.
Usually UA resolves the SIP URI of the next hop when sending
a request and opens the connection towards a resolved address-port
pair. In the context of ForceTCP at least the port is not evident.

If proxy has a TCP SIP port configured to the DNS, the UA might
already have a TCP connection open towards the proxy even if the
proxy does not recognize it. Instead of opening a new TCP connection
the existing one could be used, see below. But if DNS does
not have TCP SRV record for the proxy, then which port to use ?
Always 5060 or should ForceTCP tell the port number ?


But if you anyway would like to continue with the draft, please
consider an alternative pattern.

I believe that the requirement for the UA to associate the UDP and
TCP flows together does not make sense. The proxy should maintain
this association as it is the proxy who really needs this info,
in order to remap inbound requests between flows. Consequently
the pattern could be like this:

1. Proxy receives such a big SIP request that it can not pass it
   to the UA via the persistent UDP flow
2. Consequently the proxy will send ForceTCP message to the UA.
   This message would contain the flow token of the UDP flow.
3. UA would immediately respond to the ForceTCP message
4. The UA will open a temporary TCP connection towards the proxy
   or skip this phase if it already has a persistent TCP connection
5. The UA will send a GiveToken request to the proxy over the TCP
   connection, giving the token of the associated UDP flow
6. The proxy will respond GiveToken request and store the mapping
   between the TCP and UDP flows
7. Based on the GiveToken from the UA the proxy can now re-map the
   big SIP request from UDP flow to the TCP flow and forward
   it to the UA

This pattern would also avoid ForceTCP transaction to time out
(or retransmissions of ForceTCP) while UA is opening the TCP
connection and performing the GetToken exchange.


P.S. I still have doubts whether this mechanism, introduced as a 
separate draft, would gain wide enough acceptance to be really
useful for deployments. I also anticipate that when reviewed in
detail, the complexity will grow as the problems and different
error cases etc. pop up.


Regards,

Erkki

>-----Original Message-----
>From: ext Marc Petit-Huguenin [mailto:petithug at acm.org] 
>Sent: 04.January.2007 15:31
>To: sip at ietf.org
>Subject: [Sip] draft-petithuguenin-sip-outbound-fragmentation-01
>
>I just submitted a new version of my proposal to support hybrid TCP-UDP
> transport in Outbound.  Until it appears in the archives, a 
>copy can be
>found here:
>
>http://marc.petit-huguenin.org/draft-petithuguenin-sip-outbound
>-fragmentation-01.txt
>
>This is a nearly complete rewrite.  Please read at least the
>Introduction and the Overview of Operation sections and you will see
>that this proposal does not add a lot of complexity to Outbound.
>
>Comments and questions are welcome.
>
>Thanks.
>
>-- 
>Marc Petit-Huguenin           [                                 ]
>Home: marc at petit-huguenin.org [ RFC1855-compliant space for rent]
>Work: marc at 8x8.com            [                                 ]
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors at cs.columbia.edu for questions on current sip
>Use sipping at ietf.org for new developments on the application of sip
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip