Subject: [Trigtran] TCP & Link Outages

From: Reiner Ludwig <[email-masked]>
Date: Wed, 27 Nov 2002 13:26:57 +0100

at the BOF in Atlanta we were talking about the link layer advice from 
draft-ietf-pilc-link-design-12.txt in case of link outages. This is the 
relevant text from section 8.2:
    It is therefore highly desirable that a subnetwork subject to outages
    not silently discard packets during an outage. Ideally, it should
    define an interface to the next higher layer (i.e., IP) that allows
    it to refuse packets during an outage, and to automatically ask IP
    for new packets when it is again able to deliver them. If it cannot
    do this, then the subnetwork should hold onto at least some of the
    packets it accepts during an outage and attempt to deliver them when
    the subnetwork comes back up. When packets are discarded, IP should
    be notified so that the appropriate ICMP messages can be sent.

    Note that it is *not* necessary to completely avoid dropping packets
    during an outage. The purpose of holding onto a packet during an
    outage, either in the subnetwork or at the IP layer, is so that its
    eventual delivery will implicitly notify TCP that the subnetwork is
    again operational. This is to enhance performance, not to ensure
    reliability -- a task, that as discussed earlier, can only be done
    properly on an end-to-end basis.

If you would like to see real world measurements that show how nicely this 
works for TCP, you can check slide no. 12 from a talk I gave at the PILC WG 
meeting in San Diego. It's available here http://pilc.grc.nasa.gov/ and the 
link is titled "Flow Adaptive ARQ Proposal".

Slide no. 13 shows how poorely TCP performs if this advice is not followed.

Having said this, I'm not convinced that we need a "Link UP" trigger, nor a 
"Link DOWN trigger.

///Reiner

_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: <[email-masked]>
Date: Wed, 27 Nov 2002 11:09:52 -0600

Hi,

I guess there is a practical aspect of explicit triggers that
needs mentioning. In many cases--depending upon where the TCP
sender is located--explicit triggers (like ICMP or any other
signaling protocol for that matter) will be blocked by firewalls.
So even if we do have explicit triggers, there will always be a
need to have implicit mechanisms built into the transport layer.
But on the other hand, implicit triggers tend to be too broad and
this certainly hurts the performance.

So whether we should have an explicit trigger or an implicit
triggers is not necessarily an either-or issue.

--Yogesh

> -----Original Message-----
> From: ext Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 10:21 AM
> To: [email-masked]
> Subject: RE: [Trigtran] TCP & Link Outages
> 
> 
> Reiner is raising a topic Sally mentioned in her talk at 
> TRIGTRAN last week - do we need explicit triggers, or would 
> implicit triggers be sufficient? Retransmitting a packet when 
> an interface becomes active looks like an implicit trigger to me.
> 
> I think the key question here is whether we think there are 
> additional interesting triggers beyond link up/link down. If 
> (no), the implicit trigger mechanism described in the PILC 
> LINK document would be sufficient, if (yes), we're probably 
> looking at an explicit trigger.
> 
> Sally also raised a minor question - is the retransmitted 
> packet useful, or just the fact that it was sent? I assume 
> that the answer is "yes for TCP, no for most other packets", 
> but am still thinking about this, and welcome other views.
> 
> Spencer
> 
> > -----Original Message-----
> > From: Reiner Ludwig [mailto:[email-masked]]
> > Sent: Wednesday, November 27, 2002 6:27 AM
> > To: [email-masked]
> > Subject: [Trigtran] TCP & Link Outages
> > 
> 
> [ deleted down to ]
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 27 Nov 2002 13:26:56 -0600

Hi, Yogesh,

Yes, exactly. We're not turning off any of the implicit mechanisms that exist today, the question is whether explicit triggers would be significantly useful, in addition.

Definitely not either/or.

Spencer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 11:10 AM
> To: Spencer Dawkins; [email-masked]

---

From: <[email-masked]>
Date: Wed, 27 Nov 2002 13:52:23 -0600

> Exactly. It could be as simple as a new ICMP "reinitialize congestion 
> control" message type. If a firewall blocks it, that wouldn't 
> be too fatal 
> since the standard TCP/SCTP/DCCP congestion control rules 
> would still be 
> applied.
> 
> - Pasi

It will be interesting to see how this will work, given all the security 
issues involved. It's naive to think that a TCP sender can have a 
security association with a random router in the network ==> we cannot 
have any public/private key schemes. So the bulls other eye for security 
will be to use cookies. Again, its not possible to have a 
cryptographically safe cookie exchange without any security association 
between the "smart router" and the TCP sender. But even if there did 
exist such a mechanism, all these cookies will have to carried as either 
IP options (not my favorite) or as TCP options which is already too 
crowded. In addition all these cookies will have to be carried in each 
and every packet. The third choice is to use TCP sequence numbers as a 
loose form of cookie exchange. But anyone who can eavesdrop on any link 
between the TCP sender and TCP receiver can get all the needed 
information. 

So before we say we can solve congestion related problems using explicit 
signaling we should first have a complete solution for securing such
signals. This discussion is meaningless, otherwise.

--Yogesh

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 27 Nov 2002 14:25:40 -0600

Hi, Yogesh,

Keeping in mind that the TRIGTRAN problem statement draft had more questions than answers about security ...

It's probably worth keeping in mind that anyone who can dork with these explicit messages can dork with at least some of today's implicit triggers - if you're on the path to a receiver, just drop some packets, for instance, or forge ACKs guessing sequence numbers and overrun the bandwidth-delay product when the sender responds to them.

But we do need to look at who trusts who, and why, in each scenario we look at.

Spencer 

> Sent: Wednesday, November 27, 2002 1:52 PM
> To: [email-masked]; [email-masked]
> Cc: Spencer Dawkins; [email-masked]
> issues involved. 

[ deleted down to ]

---

From: <[email-masked]>
Date: Wed, 27 Nov 2002 15:36:53 -0600

Hi,

please see my comments below:

> Hi, Yogesh,
> 
> Keeping in mind that the TRIGTRAN problem statement draft had 
> more questions than answers about security ...
> 
> It's probably worth keeping in mind that anyone who can dork 
> with these explicit messages can dork with at least some of 
> today's implicit triggers - if you're on the path to a 
> receiver, just drop some packets, for instance, or forge ACKs 

I was not saying that TCP as it is does not have any security holes, but 
with explicit triggers we will have even more holes than what we  
already have. So I doubt, for example, if any web sever manager will 
be willing to use a high performance TCP server with twice as many 
security holes than a low performance TCP server with fewer security 
holes. (BTW, as a side note, dropping a packet is far more difficult 
than forging an ACK etc...)

I think TRIGTRANS will be useful if we can have better performance 
without having to make other compromises. But I don't know how much 
better the performance could be. For example (which was used by 
others), if there is a bit error loss every 1000 packets (with an 
average cwnd of 10), its probably okay to have the congestion window 
halved even though the loss was not due to congestion. Clearly there 
is a need to weigh these options and I personally don't know the 
answer.

--yogesh