Subject: [tcpm] ICMP and TCP

From: "Bora Akyol" <[email-masked]>
Date: Fri, 19 May 2006 10:48:47 -0700

Should we stop beating around the bush and cut the cord between these
two altogether? Even
PMTU discovery is really an L3 function.
 
What the icmp/tcp draft proposes turns all hard errors to soft anyway,
why not just cut the cord and
let TCP react to only the other peer TCP.
 
Bora
 
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 May 2006 10:54:19 -0700

Bora - are you suggesting that TCP should ignore all ICMPs? I
think I can understand the motivation, but some might object.
 
Fred
[email-masked]

________________________________

From: Bora Akyol [mailto:[email-masked]] 
Sent: Friday, May 19, 2006 10:49 AM
To: [email-masked]
Subject: [tcpm] ICMP and TCP

 
Bora

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2006 10:54:35 -0700

> let TCP react to only the other peer TCP.

That won't help find out when the other peer isn't there (host 
unreachable), TCP isn't there (protocol unreachable), or network isn't 
there (net unreachable).

Those turn out to be useful; if we care about short-circuiting IPv6 
attempts to fall-back on IPv4 attempts, then we ought to care as much 
about these errors, which are equivalently important.

(and when a host or net decides they're a security risk, the host or net 
can disable them)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:00:03 -0300

At 14:48 19/05/2006, Bora Akyol wrote:

>Should we stop beating around the bush and cut the cord between 
>these two altogether? Even

Would you apply the same rationale to TCP's congestion control, too?

>What the icmp/tcp draft proposes turns all hard errors to soft 
>anyway, why not just cut the cord and

The soft errors will provide more specific information about the 
error condition, in the event the connection times out.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 May 2006 02:00:03 -0300

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 09:08:34 -0700

> Would you apply the same rationale to TCP's congestion control, too?

Of course he wouldn't.

Congestion control cannot be done (only) on a per-host basis, because
individual sessions take different paths through the network and have
different mechanisms for adaptation to reduced network capacity.  (You
slow down a video stream and a file transfer using different application
and transport mechanisms, and slowing down sessions that are not passing
through a congested router is a waste of time).

While congestion *detection* is, IMHO, a legitimate L3 function, control
is a more complex endeavour.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 09:25:23 -0700

> is a more complex endeavour.

I realize that wasn't exactly helpful to the discussion, but you know
how congestion control gets the better of me.

I do have sympathy for the position that TCP should be ICMP-independent,
using ICMP messages only as hints.  PMTUD seems to be the big stumbling
block in that perspective, and the sooner we have ICMP-free PMTUD the
happier I'll be.

However, there are two issues on the table here:

	1. Given the world in which we live, is the ICMP attacks draft
	   a reflection of group consensus yet?

	2. Should we also be writing a draft/taking a position on
	   ICMP-free TCP?  Does that generalize?

Let's try to keep those clear while we are discussing.  And try not to
tease me with congestion control discussions. :-)

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 09:37:07 -0700

Ted Faber wrote:
...
> 	   ICMP-free TCP?  Does that generalize?

I don't think we should be writing that; that's a TSVWG issue, unless we 
have magic to explain why TCP should be the lone, first, or otherwise 
unique protocol to start deprecating ICMP.

I agree that ICMP is an issue, and that the Internet is a mess. But 
standardizing incremental hacks to tweak TCP to fix that isn't a good 
way forward, regardless of what's deployed.

Which goes to your first point, but my position on that is already clear.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 10:10:34 -0700

> way forward, regardless of what's deployed.

If by "standardizing" you mean issuing an RFC on the standards track,
that's not the current plan for this document.  The last time we asked,
at IETF-64 (http://tools.ietf.org/wg/tcpm/minutes?item=minutes64.html),
the group consensus was clearly for BCP or informational.

If by "standardizing," you mean writing anything at all, well you're
clearly on the wrong side of consensus.  The last time we asked about
that (same meeting), there was no opposition at all.

The issue is what to say. Documenting current practice or analyzing
the choices open to implementors seems reasonable to me.  Y'know,
without my hat on.

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 May 2006 10:35:39 -0700

Ted Faber wrote:
> that's not the current plan for this document. 

That's what I meant.

> The last time we asked,

Sure.

...
> the choices open to implementors seems reasonable to me.  Y'know,

*always*.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 11:02:59 -0700

> >that's not the current plan for this document. 

Then, be reassured.  Informational/BCP is the plan. 

> >the choices open to implementors seems reasonable to me.  Y'know,

I do wear the chair hat *sometimes*.   When Mark's not looking.  Just
not now.