Subject: [Int-area] more feedback on draft-van-beijnum-multi-mtu-02

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2008 12:46:44 -0700

Some comments below:

Abstract - notes ethernets as ubiquitous shared LANs; how about cable 
internet? Also, ethernets are largely switched except for 802.11

Sec 1.0 - #1 in the list, the header overhead issue seems unimportant; 
once you're up in 1500B range, the 3-5% overhead doesn't drop enough to 
matter much to make packets much larger.

#4 in the list (TCP perf) seems derivative of #2. Note that congestion 
control also becomes potentially more variable, because the granule of 
response is larger. More on this below...

4821 should be referenced by name (Packetization Layer PMTUD)

The second list (end sec 1) seems IPv6-specific, except for IPv4. It 
would be useful to indicate which items are for which protocol version.

Sec 3.0 - packet loss due to congestion needs to be included as a 
separate item in the list; note that larger packets makes this worse 
(fate sharing)

Sec 3.1 - apps care about paths, notlinks. I.e., the issue is the BW of 
the path, not the link. This begs the overall question of whether this 
makes fragmentation worse in some cases.

Sec 3.2 - again, this section focuses on what's best for links, not 
paths. Large packets on a link aren't always good for the path. Also, 
agreed that the core is fast, but IMO the edge is fairly fast too; it's 
the access network that is the bottleneck (due to explicit provisioning 
based on pricing, if not capacity)

The discussion of fate sharing of cost/benefits isn't convincing; there 
are many parties here (src, router, dst), and the benefits are at all 
three, where the problems are largely only at the router AFAICT. The 
fate isn't shared.

Sec 3.4 appears to ignore congestion control losses. I wonder if cong 
control dominates loss anyway, at which point BER optimization would be 
noise.

Sec 4.2 - you've focused largely on IPv6 to this point; overall, a 
comprehensive discussion of both IPv4 and IPv6 would be useful.

Sec 4.5 - the SHOULD appears to apply only to shared links; it seems 
like that caveat should be included.

I am concerned about having the link layer think it should ever override 
TCP (w.r.t. MSS, here). This was explored in several BOFs, and overall 
at best only safe, recoverable optimizations are appropriate. I am not 
sure whether this is either safe or recoverable (I'm not sure it's not, 
but that should be discussed).

Sec 4.6 - I am concerned about options that MUST come last; this means 
this doc overrides all other IPv6 option descriptions. That may impede 
its deployment and/or acceptance.

Sec 4.7 - again, this option seems like it is appropriate only on shared 
links; is there a way to limit it to those kinds of links? Does this 
requirement make IPv6 more fragile / unnecessarily complex in pt-pt 
links by adding a requirement that isn't needed?

If the packet is lost, it seems like repeating it a few times is a SHOULD.

Sec 4.8 - this too seems like it SHOULD be repeated if lost.

Sec 4.9 - it's not clear why probing at at least twice the segment size 
isn't the minimum required; finding the larger MTU is helpful only to 
the extent that it reduces overhead, packet frequency, etc., and 
increases smaller than a factor of 2 or so seem moot and not worth 
over-tuning.

Sec 5 - I am not in favor of transport flags. As per above, I don't 
think the link should be telling an E2E protocol anything; it's not 
appropriate.

Sec 6 - replace "serve" with "service".

--

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Mar 2008 12:54:23 -0700

High order bits, FWIW:

- this solution appears to ignore congestion-based losses
	large packets make that worse, not better

- this solution appears to ignore the impact on congestion control
	feedback systems react in chunks of an MTU, typically
	making that chunksize larger discretizes the congestion
	response, making it less smooth

	(this expands the point I said I'd explain later...)

- this solution should NOT interact with transport layers
	those layers can detect the interface MTU or changes
	to the extent they're prepared to already
	changes to the MTU will affect new connections already;
	affecting in-progress connections may not be appropriate,
	and is more complex than its corresponding benefit, IMO

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 Mar 2008 11:58:29 -0400

Thanks for the comments, Joe. I'll address most of them in a new  
version of the draft.

On 11 mrt 2008, at 15:46, Joe Touch wrote:

> Sec 1.0 - #1 in the list, the header overhead issue seems  
> unimportant; once you're up in 1500B range, the 3-5% overhead  
> doesn't drop enough to matter much to make packets much larger.

Right, 3% or 2% overhead isn't really an issue. However, at 1500 bytes  
with IPv6 and the TCP timestamp you only get 1448 payload bytes out of  
your 1500 byte MTU and ethernet adds 18 bytes + the equivalent of 20  
bytes for the preamble and inter-frame gap so you're using 1538 bytes  
on the wire, so you're only 94.1% efficient and if you add a TCP ack  
for every 2 data segments it's even worse at 90.9%.

> Sec 3.1 - apps care about paths, notlinks. I.e., the issue is the BW  
> of the path, not the link.

Right, but we don't know the bandwidth of hops in the middle, only the  
bandwidth at the two endpoints. This is why it's important that  
administrators can set a maximum packet size.

> Sec 4.5 - the SHOULD appears to apply only to shared links;

It doesn't.

> I am concerned about having the link layer think it should ever  
> override TCP (w.r.t. MSS, here). This was explored in several BOFs,  
> and overall at best only safe, recoverable optimizations are  
> appropriate. I am not sure whether this is either safe or  
> recoverable (I'm not sure it's not, but that should be discussed).

You told me that BSD probably already overrules the MSS options on  
sessions on the local subnet. If that's true, the draft is actually  
more conservative than current practice. Because per-neighbor MTUs  
aren't known when a session is first set up, it's not possible to  
advertise an appropriate 1500+ MSS. Having to stick with 1500 bytes  
when the correspondent says it can handle something much larger seems  
rather suboptimal, so I assume that implementers will want to work  
around that. By having this bit, a host can explicitly tell another  
host what its wishes are in this regard, so there is no chance that  
bad things happen unintentionally.

So if you don't want to overrule the MSS, set the bit to 0 on send and  
ignore it on reception, send only packets that fit in the MSS and  
there's no danger that others will be sending you larger packets.

> Sec 4.6 - I am concerned about options that MUST come last; this  
> means this doc overrides all other IPv6 option descriptions. That  
> may impede its deployment and/or acceptance.

This is a consequence of the breaking of the 8 byte alignment in case  
we want to pad to something that isn't 8 byte aligned. If we agree  
that we don't want to do that this restriction is unnecessary.

> Sec 4.7 - again, this option seems like it is appropriate only on  
> shared links;

The opposite. On a shared link you know that packets of a certain size  
make it through or not so no need to probe. Probing discovers switches  
with limited MTU sizes.

> If the packet is lost, it seems like repeating it a few times is a  

Both sides will initiate this so two packets must be lost before a  
retransmission is really needed. It doesn't seem worth the complexity  
to do those retransmissions just to cover the case where two packets  
are lost. The mechanism will also restart after an idle period when  
entries were garbage collected from the neighbor cache.

> Sec 4.9 - it's not clear why probing at at least twice the segment  
> size isn't the minimum required;

Even a 1508 byte MTU can be useful: this gives you a 1500 byte MTU  
after applying PPP over ethernet.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Mar 2008 10:05:42 -0700

I thought this whole discussion seemed oddly familiar; we
had essentially the same one 5 years ago:

  http://www.ietf.org/mail-archive/web/ipv6/current/msg00446.html
  http://www.ietf.org/mail-archive/web/ipv6/current/msg00475.html
  etc. etc.

Also, I made the comment at the mike that maximum per-nbr MTU
information could be used in conjunction with the SEAL approach.
See the following draft (dated 10/30/02) that essentially
proposed this:

  http://www3.tools.ietf.org/html/draft-templin-v6v4-ndisc-01

Fred
[email-masked]
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area