Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps)

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Tue, 05 Aug 2003 08:49:59 -0500

Caitlin Bestler wrote:

>
> On Monday, July 21, 2003, at 09:35 AM, Armando L. Caro Jr. wrote:
>
>>>
>>
>> Well, your one bit solution only works if the sender follows the
>> recommended mechanism for retransmissions. There hasn't been a consensus
>> that retransmitting on an alternate path is always the best policy. In
>> fact, I would argue that it isn't. I believe that for better performance
>> without affecting failover performance, fast retransmits should go to 
>> the
>> same destination and timeout retransmits should go to an alternate
>> destination [1].  With such a retransmission policy, one bit would
>> not be enough. Sure we could use 2 bits, but timestamps just seems
>> cleaner.
>>
>> [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf
>>
>> ~armando
>>
>
> In the paper cited, you fault the default SCTP behavior for assuming
> "that loss indicates either that the destination address used is 
> unreachable,
> or the destination's network path is congested."
>
> The implication is that the end-to-end algorithm is "giving up too 
> quickly"
> on a path, and thereby degrading performance.
>
> As that I have seen this objection most often raised when the final hop
> is a mobile and/or wireless link, I am tempted to turn that question 
> around.
>
> Isn't the real problem that the last hop is giving up on L2 delivery too
> quickly, and creating an L3/end-to-end problem for something that
> should have been handled locally?
>
> Basically, is each downstream frequency *really* a path? Or should
> the collective set of frequencies be viewed as a single L3 path
> over which there may be L2 retries?
>
> I designed a two-way CATV system to carry IP traffic through
> set-top decoders while I was at Zenith Electronics. Whenever
> the set-top needed to change frequency it would be deaf to
> the headend for a short period. Realizing that dropping
> packets during such a frequency shift would lead to very
> poor end-to-end performance, we simply scheduled the
> packet to be L2-delivered on a frequency as soon as it
> was known, or on all frequencies if the receiver's status
> was not known.
>
> We certainly do not want to begin an L2 design debate
> here, but I think it is a valid question -- is it a valid assumption
> that L2 delivery should be dealing with truly transitory
> problems and therefore packet loss really should be
> taken to as an indication that the destination address used
> is unreachable or the destination's network path is
> congested? 

Caitlin:

As always an interesting comment from you..( yes I have a lot of
other unread email that you have sent to me .. I will get to it I 
promise :>)

Now I understand the logic here and I have two comments...

a) Being able to seperate a L2 drop for NON congestion reasons from the
    "default" assumption would be a nice thing.. I actually will have a 
proposal
    to put forward on this later on when I can get the cycles to clean 
up the drafty
    draft I have in the works somewhere :>

b) If your example L2 environment just delivered the packet late (as I 
assume it
    must have) then what you have is a spurious retransmission.. the 
very thing
    that Eifel is trying to detect...

Just a thought or two :>

R

>
>
> Caitlin Bestler - [email-masked] - http://asomi.com/
>
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
>
>

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 05 Aug 2003 18:14:10 -0500

Both Randy and Caitlin's comments below are indeed very interesting. I
wonder if we still have consensus that SCTP is still an end-to-end, L3
transport protocol. If so, I believe the reason we call it end-to-end is
because we assume there is a virtual, structure-less, vairable
bandwidth, end-to-end pipe underneath the L3 transport. 

Now, I start to see people talking about "what if the last hop of the
pipe [between two SCTP ends] is of X or Y nature". To me, at layer 3 I
don't see any internal structure of the L2 pipe execpt of the assumption
that it is an end-to-end pipe. So where is that "last hop" people are
referring to?

If this virtual pipe abstraction no longer holds, then we are in a new
era of layering principle. If it is still valid, then the "last hop" is
invisible to SCTP and needs to remain so. And the nature of the "last
hop" needs to be addressed in L2 groups (e.g., trigtran).

In short, I fail to see how we could succeed by tweaking L3 SCTP to
address some L2 "last hop" characteristics.

regards,
-Qiaobing

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 5 Aug 2003 18:28:37 -0500

> address some L2 "last hop" characteristics.

It is really a matter of what the best interpretation of
the "end to end" assumption is.

Most of what has been written recently emphasizes that the
L2 layer should not attempt to solve L3 problems.

But it strikes me that you can go too far in the opposite
direction. When a given L2 hop is significantly more likely
to have bursty transmission errors than the Internet as
a whole, I really think we need to question whether those
problems should be solved on and end-to-end basis.

That is especially so if there is a suggestion that the
end-to-end algorithms need to adjust because they react
incorrectly to bursty noise on one hop.

If a typical path does only shows frequent drops when
there are failures and/or congestion, then SCTP assuming
a shift in path remains the correct strategy.

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 05 Aug 2003 19:33:19 -0500

Caitlin Bestler wrote:
...
> incorrectly to bursty noise on one hop.

I *think* we are in agreement here :-) 

SCTP CC (as well that of TCP) is designed as an end-to-end mechanism.
Therefore, I'd think any tweak on this end-to-end mechanism will by
definition have an end-to-end impact through the entire pipe. So, if we
can really devise a particular tweak that is "just right" to address the
particular noise/burst pattern of one hop in the pipe, in all the
likelihood, this tweak will be suboptimal or even adversely impact the
other hops in the pipe. And this would not be good.

regards,
-Qiaobing

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Wed, 06 Aug 2003 06:54:03 -0500

Qiaobing:

Yes, I do agree with you... but then do you think
that a router sending a ICMP message that the transport
protocol uses to determine path mtu is bad?

I look at it not as a LAST hop .. but that at ANY point in the
path a router can make a decision to either
1) drop a packet due to congestion
or
2) drop a packet due to corruption

In case <1> we WANT the transport protocol to react
to it and reduce its sending rate. But in case <2> we would
prefer the transport protcol become aware of this drop and to
retransmit it (if retransmission is so desired) WITHOUT reducing
its congestion rate... This in theory could be ANY hop along a
routing chain.. but in most cases would be the last or next to
last hop.. I am thinking satellite transmission for next to last...

Now the problem as always been with reporting a corruption drop that

A) A mallicious receiver could figure out that a TSN is missing and generate
    such a report to get the sender to avoid <1>.
B) A new form of attack could be created that lets a hacker spew forth 
bunches
    of these things to "slow" down everyone else talking to a web server so
   he/she gets better service..

So how can a transport protocol trust the requests?

SCTP of course can help in that if the router has the packet that
it is deciding to drop  it can return it .. and the vtag can be checked
this helps in situation <B> but what about <A>...

The packet corruption may be at a point that the sender can't
verify it? This is true.. and if so it should be tossed...

The new technology we have created at cisco however is a tunneling
software that does some retransmission.. and will give up on
that retransmission think of it as an RLP.. but when it does
give up .. its capable of sending the packet back to the sender..

I will get a draft together on this soon... I am just short of cycles right
now...

I have this up and running and its simulation results for working with
satellites is remarkable.. you can get speeds that normaly take the
disruptive PEP arpproach.. aka where you terminate the TCP/SCTP
at both sides of the satellite to "fool" the end to end protocol into
not realizing the long bandwidth delay by-product.. very ugly...

When I present my draft I will also include some performance
work I have gatherede too...

R

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 6 Aug 2003 08:23:54 -0500

Dear Caitlin,

> incorrectly to bursty noise on one hop.

I happen to agree (this was where TRIGTRAN ended up,
oriented to first-hop wireless links because that's the link
where the problem was for users in my part of the Internet).

Having already agreed, "but..."

One problem we ran into was, what happens if you're solving
a specific problem and somebody morphs the topology
underneath you?

In TRIGTRAN, the focus was on wireless WAN links, but
WLAN links are so cheap now that they're built into some
computers by default, so the problem changed from RTO
backoff when there's no coverage to path change when
there's dual coverage.

In TRIGTRAN, we headed off toward "last-hop" link
problems just in time for people to start putting networks
at the other end of the "last-hop" link, so it wasn't a last-hop
link any more.

The pressure was on us to beat end-to-end mechanisms,
without negative impacts even in situations we hadn't
anticipated. This isn't impossible, but it IS a tough sell.

In the SCTP case, what happens if there are TWO
problematic links on the path? You have to make sure
that the two independent repair processes aren't working
at cross purposes and will finish repairs at least as quickly
as end-to-end mechanisms would.

This isn't impossible, but it IS a tough sell.

Spencer

----- Original Message ----- 
From: "Caitlin Bestler" <[email-masked]>
To: "Qiaobing Xie" <[email-masked]>
Cc: "Randall R. Stewart (home)" <[email-masked]>;
"Armando L. Caro Jr." <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 05, 2003 6:28 PM
Subject: Re: [Tsvwg] Meaning of path failure (was re SCTP Timestamps)

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 06 Aug 2003 17:42:03 -0500

Randy,

Your email below shows perfectly what is the right way to address this
type of L2 problem - it is going to be a collaboration and interaction
between L2 and L3! The router's involvement (dropping the packet) and
feedback (sending back the Vtag) to L3 are the key here. The point I was
trying to make in my original email was that we are unlikely to
correctly address a L2 problem by tweaking L3 alone.

regards,
-Qiaobing