Subject: [v6ops] new draft: draft-byrne-v6ops-64share

From: <[email-masked]>
Date: Sat, 29 Sep 2012 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at it and comment.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 29 Sep 2012 19:35:39 +0200 (CEST)

> A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at it and comment.

I have read it and support that it's a valuable topic to publicise an RFC 
on.

The last paragraph of section 3 about MTU makes sense, but I would like to 
see a little bit more elaboration on why 1440 was chosen (rationale). I 
understand the rationale, but I am not sure all readers of the document 
do.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 29 Sep 2012 17:58:27 +0000

Good and concise document indeed, there is a typo in the addresses 2001:db8:: becomes 2001:db80:: :-)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mikael Abrahamsson
> Sent: samedi 29 septembre 2012 19:36
> To: Fred Baker (fred)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share
> 
> > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-
> v6ops-64share. Please take a look at it and comment.
> 
> I have read it and support that it's a valuable topic to publicise an RFC on.
> 
> understand the rationale, but I am not sure all readers of the document do.
> 
> --
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 29 Sep 2012 12:26:04 -0700

On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> A new draft has been posted, at
>> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at
>> it and comment.
>
>

I tried to keep it concise, and the MTU issue is quite important and
does require explanation, as you mentioned ... but on thinking it over
more, it would be better to simply reference this behavior in the more
comprehensive draft-binet-v6ops-cellular-host-reqs-rfc3316update

So, i will remove the MTU bit from draft-byrne-v6ops-64share and just
make sure it gets covered well in
draft-binet-v6ops-cellular-host-reqs-rfc3316update

FYI to folks that might be lost here. The 3GPP architecture is heavily
reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling protocol).
More often than not, the infrastructure links are set at 1500 bytes,
the cell phone interface is 1500 bytes, and therefore the GTP tunnels
packets need to fragmented since they are carrying 1500 byte tunneled
packets within an IP packet that will no longer fit on a 1500 byte
link.  Not pretty.  So, sometimes the carriers get the handsets
manually set to a lower MTU. And, sometimes the HTTP proxies reset the
MSS to avoid fragments.

Given that RA can advertise MTU, this is a good opportunity to
properly and dynamically set the mobile device's MTU without causing
lots of fragment reassembly state in the network or otherwise mucking
with MSS.  This will also be relevant and true for devices on the
tethered LAN since all those packets will be put into the MTU
constrained GTP tunnels on their way through the mobile provider and
to the Internet.

CB

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 29 Sep 2012 21:27:16 +0000

Isn't it easier to copy the MTU option from the RA received by the handset to the RA sent on the LAN? Of course, when there is no MTU option in the received RA on the WAN link, then, a SHOULD set MTU option to 1480 seems good

-éric

> Cameron Byrne
> Sent: samedi 29 septembre 2012 21:26
> To: Mikael Abrahamsson
> >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a
> >> look at it and comment.
> >
> >
> > The last paragraph of section 3 about MTU makes sense, but I would
> > like to see a little bit more elaboration on why 1440 was chosen
> > (rationale). I understand the rationale, but I am not sure all readers of
> the document do.
> >
> 
> I tried to keep it concise, and the MTU issue is quite important and does
> require explanation, as you mentioned ... but on thinking it over more, it
> would be better to simply reference this behavior in the more comprehensive
> So, i will remove the MTU bit from draft-byrne-v6ops-64share and just make
> sure it gets covered well in draft-binet-v6ops-cellular-host-reqs-
> rfc3316update
> 
> More often than not, the infrastructure links are set at 1500 bytes, the cell
> phone interface is 1500 bytes, and therefore the GTP tunnels packets need to
> fragmented since they are carrying 1500 byte tunneled packets within an IP
> packet that will no longer fit on a 1500 byte link.  Not pretty.  So,
> sometimes the carriers get the handsets manually set to a lower MTU. And,
> sometimes the HTTP proxies reset the MSS to avoid fragments.
> 
> Given that RA can advertise MTU, this is a good opportunity to properly and
> dynamically set the mobile device's MTU without causing lots of fragment
> reassembly state in the network or otherwise mucking with MSS.  This will
> also be relevant and true for devices on the tethered LAN since all those
> packets will be put into the MTU constrained GTP tunnels on their way through
> the mobile provider and to the Internet.
> 
> CB
> 
> > --

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 29 Sep 2012 14:50:49 -0700

> Isn't it easier to copy the MTU option from the RA received by the handset to the RA sent on the LAN? Of course, when there is no MTU option in the received RA on the WAN link, then, a SHOULD set M…

Yes, this will be the logic that we will bring to the text of
draft-binet-v6ops-cellular-host-reqs-rfc3316update

CB

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 29 Sep 2012 19:56:23 -0700

It is not required that the same address be assigned on both interfaces,
just that the UE must defend and respond for the address used on the wan
interface as if it was connected to the lan. I can't think of any cases
where using the duplicated address breaks anything, but it does seem like
there might be some diagnostic benefit to having a predictable offset on the
lan interface address. It is not like there is a shortage of addresses and
we need to duplicate as a conservation measure... ;)

Tony

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cameron Byrne
> Sent: Saturday, September 29, 2012 2:51 PM
> To: Eric Vyncke (evyncke)
> > Isn't it easier to copy the MTU option from the RA received by the
> > handset to the RA sent on the LAN? Of course, when there is no MTU
> > option in the received RA on the WAN link, then, a SHOULD set MTU
> > option to 1480 seems good
> >
> 
draft-binet-v6ops-
> cellular-host-reqs-rfc3316update
> 
> CB
> 
> > -éric
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Cameron Byrne
> >> On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson
> >> <[email-masked]>
> >> wrote:
> >> >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take
> >> >> a look at it and comment.
> >> >
> >> >
> >> does require explanation, as you mentioned ... but on thinking it
> >> over more, it would be better to simply reference this behavior in
> >> the more comprehensive
> >> FYI to folks that might be lost here. The 3GPP architecture is
> >> heavily reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling
> protocol).
> >> constrained GTP tunnels on their way through the mobile provider and to
> the Internet.
> >>
> >> CB
> >>
> >> > --

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 1 Oct 2012 02:03:54 +0200

On Sat, Sep 29, 2012 at 09:27:16PM +0000, Eric Vyncke (evyncke) wrote:
> handset to the RA sent on the LAN?

Why on earth should the WAN link MTU influence the LAN MTU? The LAN has
a fixed MTU and shall never get modified ad hoc because of MTU
properties changing on other links. This is just a broken concept.
Please don't ever go down that road.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 1 Oct 2012 02:08:08 +0200

> draft-binet-v6ops-cellular-host-reqs-rfc3316update

I strongly disagree with that. Let PMTUD do its work, it's there
for that. I really really don't want to see routers on a LAN
arbitrarily mucking around with the LAN MTU to work around random
problems of upstream infrastructure.

This artificial MTU lowering in the LAN also breaks connectivity with
nodes statically configured, disregarding RAs. Suddenly you have nodes
with interface MTU=1500 trying to communicated with other nodes on the
same LAN with other, RA-derrived lower MTUs...

Best regards,
Daniel

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Oct 2012 00:53:54 +0000

+1. 

As attractive/feasible as relying on WAN MTU for LAN MTU purposes, I also disagree to that. 

Cheers,
Rajiv

Sent from my Phone

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 30 Sep 2012 18:49:52 -0700

Daniel,

> I strongly disagree with that. Let PMTUD do its work, it's there

ACK.  PMTU must do it's job.

> problems of upstream infrastructure.

Allow me to reiterate that this is something for
draft-binet-v6ops-cellular-host-reqs-rfc3316update and not
draft-byrne-v6ops-64share (it will be removed )

That said, it is not "arbitrarily mucking around with the LAN MTU to
work around random problems"

It is in fact deterministicly working around a systemic problem in
3GPP network using the correct IETF tools to do so: RA MTU info.

Keep in mind, this problem is "solved" today by "adjusting" the MSS in
HTTP proxies, which are also common in 3GPP networks.  Nobody asked
for the IETF's permission for this pervasive yet effective technique
(which is also common in DSL network, and will soon popup in DS-lite
networks... but IPv4 does not have RA to communicate the MTU)

Yes, PMTU will discover the correct MTU.  But why not start out in the
right place?  If the 3GPP network operator knows that the MTU is of
the WAN link is 1440, why not cascade the information down via RA ?
RA has this ability and it has clear benefits of not having to
exercise PMTU or adjust for it's brokeness.

Furthermore, specific to 3GPP networks, the fragmentation will not be
seen by any endpoints and PMTU will not be used. The fragmentation in
question here happens at the GTP IPv6 in IPv4/UDP tunnel.  So, the
3GPP network operator is trying to clamp MTU of the end nodes to avoid
the IPv6 in IPv4/UDP GTP mobility tunnel from being fragmented... not
the IP packets that the end nodes see.

> same LAN with other, RA-derrived lower MTUs...

PMTU will be quicker and more effective in a LAN than a WAN if this
problem occurs.

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 1 Oct 2012 15:17:33 +0900

> problems of upstream infrastructure.

Bad idea. PMTUD causes a ~1 RTT latency hit to every new server you talk to.

Why do you need 1500 anyway? So that devices talking to each other via the
phone's hotspot (!) can use 1500-byte packets instead of 1480-byte packets,
thus gaining a whopping 0.05% performance boost? ((1440÷1500) / (1420÷1480)
- 1) That's really not worth the latency hit. Even if you could to use
jumbo frames of infinite size, that's still only a 1.4% performance boost.

> same LAN with other, RA-derrived lower MTUs...

Statically configured addresses on the tethering hotspot? How would that
even happen, given that in most cases your prefix is dynamically assigned?
If you don't know the prefix in advance, you can't configure the address.