Subject: Re: [tram] TURN and fragmentation

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 19 Aug 2014 09:15:31 +0000

> -----Original Message-----
> From: Tirumaleswar Reddy (tireddy)
> Sent: Monday, August 18, 2014 9:17 PM
> To: 'Simon Perreault'
> Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;
> [email-masked]
> Subject: RE: [tram] TURN and fragmentation
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [tram] TURN and fragmentation
> >
> > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy)
> > <[email-masked]> wrote:
> > > Yes, I am referring to STUN fragmentation.
> >
> > Got it, thanks.
> >
> > 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).

Thinking aloud. STUN fragmentation problem can be solved by the following approach:
[1] Introduce a new STUN FRAGMENT attribute which carries the fragmentation details like (M: More fragments: which is set on all fragments but the last fragment),  S (Fragmentation start), Identifier for sequencing etc.).
[2] STUN attribute that would be subjected to fragmentation should be placed after the STUN FRAGMENT attribute.
[3] TURN server uses a new STUN attribute let’s say ACK to signal back to the client that it received the fragment by signaling back the Identifier it received in request. 
[4] Once the final fragment is received, TURN server merges the fragments, validates the STUN message and responds back to the client.

-Tiru

> Cheers,
> -Tiru
> > Thanks,
> > Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 21 Aug 2014 21:57:24 -0700

On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> [1] Introduce a new STUN FRAGMENT attribute which carries the
> fragmentation details like (M: More fragments: which is set on all
> fragments but the last fragment),  S (Fragmentation start), Identifier for
> sequencing etc.).
> [2] STUN attribute that would be subjected to fragmentation should be
> placed after the STUN FRAGMENT attribute.
> [3] TURN server uses a new STUN attribute let’s say ACK to signal back to
> the client that it received the fragment by signaling back the Identifier
> it received in request.
> [4] Once the final fragment is received, TURN server merges the fragments,
> validates the STUN message and responds back to the client.
>

While I'm sure something like that would work, it seems pretty complicated
and AFAIK there is no use case that requires it at the moment. I think we
should save this for later, as opposed to solving it in turn-bis.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 Aug 2014 05:05:43 +0000

Inline [TR]

From: Justin Uberti [mailto:[email-masked]]
Sent: Friday, August 22, 2014 10:27 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; [email-masked]; Brandon Williams
Subject: Re: [tram] TURN and fragmentation

On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
> > From: Simon Perreault [mailto:[email-masked]<mailto:[email-masked]>]
> > [email-masked]<mailto:[email-masked]>
> > <[email-masked]<mailto:[email-masked]>> wrote:

While I'm sure something like that would work, it seems pretty complicated and AFAIK there is no use case that requires it at the moment. I think we should save this for later, as opposed to solving it in turn-bis.

[TR] Agreed, this proposal came up as part of discussion that it would solve the fragmentation problem for ORIGIN. After comments from Martin, there is no use case that requires this problem to be solved immediately.

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 21 Aug 2014 22:27:59 -0700

I agree with Justin, The multiple-ORIGIN use case is not important enough
to justify the invention of the whole machinery of the STUN fragmentation.

Oleg

On Thu, Aug 21, 2014 at 9:57 PM, Justin Uberti <[email-masked]> wrote:

>> [4] Once the final fragment is received, TURN server merges the
>> fragments, validates the STUN message and responds back to the client.
>>
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Brandon Williams <[email-masked]>
Date: Fri, 22 Aug 2014 11:37:06 -0400

On 08/22/2014 12:57 AM, Justin Uberti wrote:
> On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>      > [email-masked] <mailto:[email-masked]>
>      > > [email-masked] <mailto:[email-masked]>
>      > > <[email-masked] <mailto:[email-masked]>> wrote:
>     fragments but the last fragment),  S (Fragmentation start),
>     Identifier for sequencing etc.).
>     [2] STUN attribute that would be subjected to fragmentation should
>     be placed after the STUN FRAGMENT attribute.
>     [3] TURN server uses a new STUN attribute let’s say ACK to signal
>     back to the client that it received the fragment by signaling back
>     the Identifier it received in request.
> While I'm sure something like that would work, it seems pretty
> complicated and AFAIK there is no use case that requires it at the
> moment. I think we should save this for later, as opposed to solving it
> in turn-bis.

I agree that a fragmentation solution doesn't belong directly in 
turn-bis. That said, I think either turn-bis or stun-bis might need to 
provide better guidance on fragmentation. For example, the current 
wording limits stun messages to 548 bytes in cases where the path MTU is 
not yet known and the messages itself is not being used to probe the 
path MTU. It's easy to come up with a set of reasonable values for an 
allocate request (at least) that would violate this restriction, 
especially when you add the new origin and 3rd party auth attributes. In 
the rare case of a client that really does have such a small PMTU, the 
standards as currently published can actually prevent the client from 
being able to use a turn relay that relies on the new attributes without 
ignoring the fragmentation guidance.

--Brandon

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 22 Aug 2014 16:25:06 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, August 22, 2014 9:07 PM
> To: Justin Uberti; Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; [email-masked]

Tunneling TURN over TURN for privacy proposed in http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be another reason to evaluate the reasons to support STUN fragmentation. We can remove step 3 optimization which would simplify the solution.
 
-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Aug 2014 16:56:48 -0700

I don't think RETURN requires us to handle fragmentation. As long as DATA
isn't sent recursively encapsulated, which I don't yet see a need for, the
only overhead is the 4-byte channel header.

On Fri, Aug 22, 2014 at 9:25 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Tunneling TURN over TURN for privacy proposed in
> http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be
> another reason to evaluate the reasons to support STUN fragmentation. We
> can remove step 3 optimization which would simplify the solution.
>
> -Tiru
>
> >
> > --Brandon
> >
> > --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 23 Aug 2014 02:27:17 +0000

Chrome seems to be using channels , but I thought other browsers like firefox are using Send/Data indications.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 5:27 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; Simon Perreault; Prashanth Patil (praspati); Alan Johnston; [email-masked]
Subject: Re: [tram] TURN and fragmentation

I don't think RETURN requires us to handle fragmentation. As long as DATA isn't sent recursively encapsulated, which I don't yet see a need for, the only overhead is the 4-byte channel header.

On Fri, Aug 22, 2014 at 9:25 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> From: Brandon Williams [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; [email-masked]<mailto:[email-masked]>
> > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > > From: Simon Perreault [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>]
> >      > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      > > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Aug 2014 23:04:15 -0700

In which case they should switch to using channels... reducing message
overhead is the whole point of channels.

On Fri, Aug 22, 2014 at 7:27 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Saturday, August 23, 2014 5:27 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Brandon Williams; Simon Perreault; Prashanth Patil (praspati); Alan
> Johnston; [email-masked]
>
> *Subject:* Re: [tram] TURN and fragmentation
>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 23 Aug 2014 14:39:58 +0000

Yup, any idea why channel is not used ?

-Tiru

Sent: Saturday, August 23, 2014 11:34 AM

In which case they should switch to using channels... reducing message overhead is the whole point of channels.

On Fri, Aug 22, 2014 at 7:27 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Chrome seems to be using channels , but I thought other browsers like firefox are using Send/Data indications.

-Tiru

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, August 23, 2014 5:27 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; Simon Perreault; Prashanth Patil (praspati); Alan Johnston; [email-masked]<mailto:[email-masked]>

-Tiru