Subject: [tram] TURN and fragmentation

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Aug 2014 08:19:29 -0400

On Mon, Aug 18, 2014 at 2:29 AM, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
> Comment on UDP fragmentation, if this problem is restricting various TURN
> drafts then why not consider enhancing TURN to handle fragmentation (similar
> to the way it’s done in EAP-TLS, DTLS handshake etc.).

TURN already has the DONT-FRAGMENT attribute which lets the client
perform packetization-layer PMTUD. Although the text could be
improved.

   So the client and server need to use a path MTU discovery algorithm
   that does not require ICMP messages.  The Packetized Path MTU
   Discovery algorithm defined in [RFC4821] is one such algorithm.

   The details of how to use the algorithm of [RFC4821] with TURN are
   still under investigation.  However, as a step towards this goal,
   this version of TURN supports a DONT-FRAGMENT attribute.  When the
   client includes this attribute in a Send indication, this tells the
   server to set the DF bit in the resulting UDP datagram that it sends
   to the peer.  Since some servers may be unable to set the DF bit, the
   client should also include this attribute in the Allocate request --
   any server that does not support the DONT-FRAGMENT attribute will
   indicate this by rejecting the Allocate request.

Are you proposing something different?

Simon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 18 Aug 2014 09:40:29 -0400

There's is also some text in STUN related fragmentation and maximum 
message sizes. Some previous discussion on the list suggested that the 
STUN text might be overly restrictive about message sizes (i.e. must be 
no larger the min MTU if path MTU is not known) and when it's OK to 
ignore the max message size guidance (i.e. only when doing something 
like PPMTUD). It may be appropriate for either STUNbis or TURNbis to 
address this.

--Brandon

On 08/18/2014 08:19 AM, Simon Perreault wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Aug 2014 09:50:36 -0400

On Mon, Aug 18, 2014 at 9:40 AM, Brandon Williams
<[email-masked]> wrote:
> There's is also some text in STUN related fragmentation and maximum message
> sizes.

Right.

There are two kinds of fragmentation that are at play here. We need to
be precise in the words we use. I don't think that there are
established terms, so let's invent them:

- "STUN fragmentation" happens between the client and the server.
- "TURN fragmentation" happens between the server and the peer.

I was referring to TURN fragmentation, and you were referring to STUN
fragmentation. Still not sure what Tiru was referring to.

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Mon, 18 Aug 2014 14:48:05 +0000

I think Tiru is referring to fragmentation between the Turn Client and
Turn Server. This leads to restrictions in the size of STUN messages. In
context of the ORIGIN draft, this restricts the size/number of ORIGIN
attributes. 

Ability to handle fragments could be useful ‹ to accommodate multiple
ORIGIN attributes and if we ever want to incorporate other parameters in
the authorization token
(http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-01#secti
on-6.2), thus increasing message size.

-Prashanth

On 8/18/14 7:20 PM, "Simon Perreault" <[email-masked]> wrote:

>>message

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 18 Aug 2014 15:27:13 +0000

Yes, I am referring to STUN fragmentation. 

-Tiru

> -----Original Message-----
> From: Prashanth Patil (praspati)
> Sent: Monday, August 18, 2014 8:18 PM
> To: Simon Perreault; Brandon Williams
> Cc: Alan Johnston; [email-masked]; Tirumaleswar Reddy (tireddy)
> Subject: Re: [tram] TURN and fragmentation
> 
> Ability to handle fragments could be useful < to accommodate multiple

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Aug 2014 11:29:28 -0400

> Yes, I am referring to STUN fragmentation.

Got it, thanks.

So, what's your idea, in detail?

Thanks,
Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 18 Aug 2014 15:47:29 +0000

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Monday, August 18, 2014 8:59 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;
> [email-masked]
> So, what's your idea, in detail ?

I have not yet figured out all the details, at high level thinking the problem can be solved similar to way fragmentation is handled in 
EAP-TLS (http://tools.ietf.org/html/rfc5216#section-2.1.5). 

Cheers,
-Tiru