Subject: Second edition of IETF Journal for your review by January 6

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Dec 2005 09:33:50 +0100

Hi,

The second edition of the IETF Journal is now in final draft.
To avoid oversights and errors, all WG Chairs, ADs, and other
members of this list are invited to review the draft. It can
be found at

http://www.isoc.org/peter/IETFJ0502-V1.doc
http://www.isoc.org/peter/IETFJ0502-V1.pdf

Please don't distribute these URLs; they are temporary.

If you have comments or suggestions to address apparent
errors, please send them by Friday January 6th
to Peter Godwin, the editor, at <[email-masked]>. After that
date, the Journal will be finalized and published.

Note that there are a couple of editor's notes/questions in
the text. If convenient, please enable track changes and
mark comments and corrections directly in the document,
and return it to Peter. There's no need to reply to this list.

Thanks, and best wishes for the holidays and a good
start to 2006.

    Brian Carpenter

---

From: Mukesh Gupta <[email-masked]>
Date: Tue, 20 Dec 2005 09:48:28 -0800

Anyone having problems in downloading this?

I tried both the pdf and the doc version.  The download stalls
after around 50% :(

Regards
Mukesh

---

From: Tony Tauber <[email-masked]>
Date: Tue, 20 Dec 2005 13:44:46 -0800 (PST)

> I tried both the pdf and the doc version.  The download stalls

Yes!  I thought it was me going crazy!

Tony

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Dec 2005 13:56:47 -0800

I downloaded the word document, and it came down fine

---

From: [email-masked]
Date: Wed, 21 Dec 2005 11:47:07 +0200

> I tried both the pdf and the doc version.  The download stalls

Yes, I have the same problem (both Nokia connection and other
ISP, both Firefox and wget from command line). I did some 
debugging, and stalling is not limited to this document, but 
also occurs on other big files on www.isoc.org.

Manually setting the SO_RCVBUF socket option to 500 bytes fixed 
the stalling, so this sounds like a PMTUD problem to me.

Suggestion to ISOC webmaster: consider manually lowering the 
interface MTU. Although the real problem (filtering ICMP messages)
may not be at your end, this will allow a larger number of
users to access your web site....

Best regards,
Pasi

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 21 Dec 2005 08:16:53 +0100

> I tried both the pdf and the doc version.  The download stalls

stalls for me too. I suspect the evil demons of PMTU at work :-(

---

From: Simon Leinen <[email-masked]>
Date: Wed, 21 Dec 2005 16:30:40 +0100

[Following up with a different Subject: line.  This doesn't have much
 to do with WG Chair business, except to show us what we have done to
 the Internet, sigh.]

Pasi Eronen writes:
> Manually setting the SO_RCVBUF socket option to 500 bytes fixed the
> stalling, so this sounds like a PMTUD problem to me.

Yes, that seems likely.  I didn't have any problems downloading the
documents, but then there's a 1500-byte MTU-clean path between the
ISOC server and me.

> may not be at your end, this will allow a larger number of users to
> access your web site....

I would assume that the problem is most likely near ISOC, because Path
MTU discovery is usually broken by the TCP-sending site (ISOC in this
case) filtering out incoming the ICMP messages that are trying to tell
the sender that it is sending too large packets.  This is corroborated
by the fact that ISOC is blocking ICMP ECHO requests (ping) towards
their FTP server as well - probably they are blocking all incoming
ICMP traffic.  I also never heard about anyone blocking ICMP packets
(at least not those required for PMTUD to work) OUTBOUND.

So I'd recommend to fix the problem at this end: Reconfigure ISOC's
inbound filters to let ICMP packets in (or at least "destination
unreachable", or at least "destination unreachable/fragmentation
needed and DF bit set" messages).  Or if ISOC is too afraid of these
ICMP packets, they should turn off PMTUD on their servers, or upgrade
to a newer version of PMTUD that doesn't require ICMP feedback - the
IETF is developing such a method, and I think Microsoft has something
called "PMTUD blackhole detection".

Lowering the interface MTU at the sender (ftp.isoc.org) is somewhat
ugly.  What would you lower it to - the lowest Path MTU to anybody who
every might want to download something from ftp.isoc.org?
-- 
Simon.

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 Dec 2005 16:38:46 +0100

> the stalling, so this sounds like a PMTUD problem to me.

May very well be so.  Another data point, without digging into
this to the extent Pasi has done:

This works for me, consistently, when downloading in OS-X,
but stalls consistently (but at different percentage of full
file size) when downloading in Linux (Debian testing/kernel 2.6.x.),
independent of the physical location (i.e., ISP).

	Henrik

---

From: Simon Leinen <[email-masked]>
Date: Wed, 21 Dec 2005 20:46:11 +0100

Henrik Levkowetz writes:
> May very well be so.  Another data point, without digging into this
> to the extent Pasi has done:

> This works for me, consistently, when downloading in OS-X, but
> stalls consistently (but at different percentage of full file size)
> when downloading in Linux (Debian testing/kernel 2.6.x.),

I believe what you are experiencing is a different problem with ISOC's
hoster's filtering setup:

I tried again and noticed that I had to turn off both ECN and SACK to
get a successful transfer of the document (this was under Solaris 10).

With ECN (RFC3168) enabled, I don't ever get a response to my TCP SYN
messages - they are just silently blackholed.

With ECN disabled, but SACK (RFC 2018) enabled, the connection starts
just fine, but when I'm starting to send SACK blocks, I receive ICMP
packets with "destination unreachable/administratively prohibited",
and the connection stalls shortly thereafter.  The time it takes for
the connection to stall is variable.

With ECN and SACK disabled, everything works nicely.

Nice lesson on what happens to our protocols when you break end-to-end
transparency - the endpoints (ISOC's server and our well-tuned
systems) successfully negotiate useful things (SACK or "large TCP
segments" - PMTUD isn't negotiated in itself) that are then blocked by
the network; and the application (in this case TCP) cannot get over
this.
-- 
Simon.