RE: [Sip] draft-gurbani-sip-lrage-udp-response-00

["Dan Wing" <[e-mail]>]

Section 2 of the document states:

   Note that UDP fragmentation and reassembly works unless there is a
   lossy link or there is a NAT between the communicating endpoints.

but there are other cases where fragmentation breaks; see
draft-heffner-frag-harmful-02.txt.  I suggest that -heffner-frag-harmful-
should be referenced by -gurbani-sip-large-udp-response.


As to NATs working well with fragmentation, it's hard to say -- are the
fragments in question sent in order, or out of order?  (I'm told that Linux
sends fragments out of order, on purpose.)  Some NATs work just fine if
packets arrive in order (the first fragment (containing the IP header)
arrives first).  But those NATs don't work well if a fragment arrives first
-- they just drop the fragment, which means the entire IP datagram will
never be completely reassembled.  Other NATs hold onto fragments if the
fragments arrive first, hoping for the arrival of the first fragment
(containing the IP header).  BEHAVE's NAT-UDP document specified the best
behavior, but it's difficult to characterize the behavior of NATs in the
wild.

-d


> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]] 
> Sent: Friday, November 03, 2006 6:26 PM
> To: SIP
> Cc: Vijay Gurbani
> Subject: [Sip] draft-gurbani-sip-lrage-udp-response-00
> 
> 
> One thing that really confused me about this draft was if seemed to  
> use the term "congestion control" when what it actually meant "can  
> deliver large packets". These seem to be two very separate things.
> 
> I think fragmentation reassembly actual does work thought most NATs.
> 
> The basic machoism seems broken. The advice that when a UAC gets a  
> 140 or 141 may later try with TCP does not make any sense to me. The  
> UA might be able to use TCP to the first proxy but there is 
> no way to  
> tell that proxy to not use UDP to the next.
> 
> Since this approach does not work, on the topic of the other proposals
> 
> Section 4.1 - it seems this one fails in usual HERFP failure mode if  
> one response is big and others are not. I think this problem should  
> be mentioned.
> 
> Section 4.2 - I have no idea what you are talking about here. 
> Can you  
> explain how this option would work?
> 
> Section 4.3 - Here you send a single possible request and 
> expect back  
> a single response but if it forks you might get back the response  
> plus *several* requests in reverse direction. The experience with  
> early media has been three are a lot of complications with this. It  
> might be the best approach but a generic description of it is pretty  
> hard. I will point out this is exactly what we are doing on all the  
> case where we do need large responses (i.e. SUB/NOT) so it might be  
> that we basically already adopted this solution.
> 
> It was not clear to me who received the 140, what they did with it,  
> or why they cared.
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip