Subject: RE: [midcom] STUN over TCP?

From: "Cedric Aoun"<[email-masked]>
Date: Fri, 15 Mar 2002 13:10:19 -0000

Mahadev,
Good point, you are right about the sequencing problem.
So TCP will be mandatory if we exceed the standard minimal MTU sizes on low
bandwidth links.
Thanks
Cedric

-----Original Message-----
From: Mahadev [mailto:[email-masked]]
Sent: Friday, March 15, 2002 11:19 AM
To: Jonathan Rosenberg
Cc: Aoun, Cedric [QPD:MA01:EXCH]; Christian Huitema; Melinda Shore;
[email-masked]
Subject: Re: [midcom] STUN over TCP?

> 
> >
> > The issue with fragmentation and NATs is when 2 NATTed clients are
> > trying to reach the same server and both datagrams are fragmented with
> > the same fragment id, the STUN server won't be able to distinguish the 2
> > client messages.
> 
> No; the problem as I understand it is that most nats won't refragment an
> IP packet. So, they totally ignore fragment bits. So, the first fragment
> will pass since it has the UDP header. But, the second one doesn't, and
> will be dropped by the NAT since it doesn't match any UDP sessions in
> progress through the NAT. Thats because the NAT thinks that there should
> be a UDP or TCP header after IP, but there won't be anything.
> 

This is not a big problem as such. There are NAT implementations which
take care of fragmentation issue by storing state information from the
first fragment. But then, this would work only if fragment 0 arrives
first.

-Mahadev

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 16 Mar 2002 15:37:15 -0800

Anecdotal evidence from the field is that no, it is no good. There is a
significant fraction of deployed NAT that just drop any fragmented
packet.

-- Christian Huitema

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, March 16, 2002 12:19 PM
> To: Mahadev
> Cc: Melinda Shore; [email-masked]
> Mahadev wrote:
> > Yes, this very common irrespective of the device type (low/high
end)...
> 
> Sorry - "this" meaning "support for fragmentation" or "no support for
> fragmentation". I'd love to see some documented tests on residential
> devices to see fragmentation support. I'd bet its not good...
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Mahadev Somasundaram <[email-masked]>
Date: Mon, 18 Mar 2002 09:09:44 -0800

the question here is, there are significant NATs which support 
fragmentation need to be considered...

-Mahadev

---

From: "Cedric Aoun"<[email-masked]>
Date: Tue, 19 Mar 2002 03:05:44 -0000

Mahadev,
This is a good way to discover the fragmentation support on the NAT. we
could use a packet size of more than 1500 bytes.

-----Original Message-----
From: Mahadev Somasundaram [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 12:55 AM
To: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH];
[email-masked]
Cc: Jonathan Rosenberg; Aoun, Cedric [QPD:MA01:EXCH]; Melinda Shore
Subject: Re: [midcom] STUN over TCP?

At 12:38 PM 3/18/2002 -0800, Mahadev Somasundaram wrote:
>At 11:34 AM 3/18/2002 -0500, Jonathan Rosenberg wrote:
>
>
>>Cedric Aoun wrote:
>> >
>> > Any way the current document doesn't impose the usage of TCP so I don't
>> > find any issue with it, but we probably want to have couple of lines to
>> > mention the real problem that we have with NATs and fragmentation and
>> > that it is not applicable to all NATs.In case the NAT supports
>> > fragmentation the STUN client is configured to use UDP.
>>
>>I will mention the motivation for TCP. However, the big question is how
>>the client knows that its nat supports fragmentation?
>one way to detect could be by sending large size packet (~5000bytes) and 
>wait for the server reply. If the  reply from server reaches the client, 
>then the NAT supports

should be read "requesting to send" instead of "sending"

thanks,
-Mahadev

>fragmentation. If there is no reply, the reason may not be due to NAT 
>fragmentation support (like packet loss, fragment out-of-sequence). So, 
>the client retransmits with the interval time of 1 second and doubles with 
>every try. After 3 tries, with the elapsed time of 7 seconds, client gives 
>up and assumes that the NAT does not support fragmentation.
>
>this could be done during the NAT discovery phase...
>
>-Mahadev
>
>