RE: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt

["Taewan You" <twyou@etri.re.kr>]

Hello Marcelo,

About this point, there seemed to be so insufficient expectation at this
draft. Thank you for giving an opportunity to explain in detail again to me.


Please, find my inline comments.

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> Sent: Sunday, July 17, 2005 1:33 AM
> To: twyou@etri.re.kr
> Cc: shim6
> Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
> 
> 
> Hi Taewan,
> 
> been reading your draft and i have some questions about it.
> 
> 
> in section 2.1 it is stated that in order to trigger TCP slow start the
> shim must:
> 
>         When any locator change was occurred, L3Shim should discard the
>         entire packets from correspondent node during TCP-Congestion-
>         Triggering-Time. Consequently the TCP congestion control
> mechanism
>         triggers naturally by this one. The main key point is that how
> to set
>         up the time of TCP-Congestion-Triggering-Time enhancing
> performance.
>         It can be heuristic setting up the value.
> 
> Now, i think this is really a bad option. I mean, forcing the shim,
> which is supposed to be a mechanisms for improving the fault tolerance,
> to discard packets does not seems a good idea to me.
> 
> So, i would like to understand a bit more why this is needed and if so,
> if there are not other approaches that can be used.
> 
> w.r.t. the alternative approaches (keep in mind that i am not a TCP
> expert)
> 
> AFAIK TCP detects congestion based on two indications: lost packets and
> duplicate ACKs. The approach presented in your draft proposed to use
> the packet loss as a mean to indicate congestion to TCP. This has the
> obvious drawback that the shim is artifically discarding packets. The
> question is : wouldn't it be possible to use the duplicate ACK
> mechanism to indicate congestion to TCP? I mean, what if, after an
> outage, the shim passes to TCP during a while artificially created
> duplicate packets? wouldn't this result in TCP detecting congestion and
> acting accordingly?
> 
> Later on, it is stated that the other action that is performed would be:
> 
>                    Also, the VALID state, which is one of L3Shim state
> and is explained
>                    in next chapter, keep up the situation expecting
> error for
>                    operational primary address pair during
> Probably-Active-Duration-Time
>                    with indirect TCP Congestion control separately, TCP
> Congestion
>                    control mechanism should be achieved automatically.
> 
> 
> Well, i fail to understand what you are proposing here, could you
> expand on this?
> 
> Regards, marcelo


As you already know, the TCP can detect packet loss using timeout occurring
and duplication ACK. The assumption of the algorithm is that packet loss
caused by damage is very small, therefore the loss of packet signals
congestion. 

AFAIK the congestion control should react upon the two situations
differently. When the timeout occurs, the TCP slow start mechanism is
operated. The other case that receive duplication ACK, the TCP fast
retransmission mechanism is operated. 

So, when an operational primary address pair should be changing, TCP fast
retransmission mechanism has been operated better than slow start for TCP
throughput. 


However, the goal of site multihoming by L3Shim6 is supporting
fault-tolerant. But the goal of I proposed vertical layered communication is
expecting congestion situation where operational primary address pair switch
from a high-bandwidth LAN interface to a low bandwidth cellular interface,
and notifying TCP to perform TCP congestion control mechanisms beforehand.

In this draft, the notification of TCP should be performed by two timers;
Probably-Active-Duration-Time, TCP-Congestion-Triggering-Time.


For instance, when the primary address pair can be detected by receiving
ICMP error message or other layer 2 information, this detected failure do
not means that an operational primary address pair's rechability cut off.
This failure should be confirm local operational address? failure only. In
this situation, we indicated the VALID state was entered. Within this state,
there is no action until decided time (Probably-Active-Duration-Time) passed
so that the TCP congestion mechanism should be operated in naturally.
For example, we can establish Probably-Active-Duration-Time to small lest
the timeout should be occurred before receiving duplication ACK, so that the
duplication ACK can be receipt for fast retransmission within timeout after
achieving address pair changes completely. On the contrary, we can set the
Probably-Active-Duration-Time is bigger so that the slow start can be
operated by timeout occurring. Consequently we can control TCP congestion
mechanism through adjustment time of Probably-Active-Duration-Time


Before, we can use TCP-Congestion-Triggering-Time for indirect TCP
congestion control, we assume that the application would be able to tell the
L3Shim layer that the current connection in unsatisfactory. Whenever address
pair is changing under the situation where changed address pair is
unsatisfied, L3Shim should discard the entire packets from correspondent
node during TCP-Congestion-Triggering-Time to occur timeout. In other wards,
we should lead to operate the slow start of TCP congestion mechanism in case
of switching from high-bandwidth to lower-bandwidth.


I'm worry about that my explanation is unsatisfied for your question. If you
have any problem or comments about this draft, please hear your comments.
I'm highly welcomed.

Regards, 
Taewan.

> 
> 
> El 15/07/2005, a las 3:30, Taewan You escribió:
> 
> > Hello folks,
> > We have submitted an I-D that describes L3Shim state management using
> > Vertical layered communication.
> >
> > In this draft, we proposed simple two ideas.
> > First is a vertical layered communication method in case of interaction
> > between L3Shim and TCP or Upper layer.
> > This mechanism is achieved using defined two timers;
> > TCP-Congestion-Triggering-Time and Probably-Active-Duration-Time.
> > Next is L3Shim state transition processes based on the events that can
> > be
> > happened during lifetime.
> >
> > We would appreciate to hear your comments.
> >
> > Regards,
> > Taewan You.
> >
> > -----------------------------------------------------------------------
> > -----
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > 	Title		: L3Shim state management using Vertical layered
> > Communication
> > 	Author(s)	: T. You, et al.
> > 	Filename	: draft-you-shim6-l3shim-state-management-00.txt
> > 	Pages		: 14
> > 	Date		: 2005-7-14
> >
> > This draft proposed vertical layered communication method; especially
> > it is mechanism to notify locator changing from L3Shim to TCP layer.
> > In this draft, it is called indirect TCP congestion control. This
> > mechanism make TCP congestion situation using behavior of L3Shim
> > layer without correcting conventional TCP. And then we describe
> > L3Shim state through the event. These kinds of events and progress
> > state are presented in a single system view. And it will be help to
> > implement L3Shim functionality through understanding L3Shim process.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-you-shim6-l3shim-state-
> > management-
> > 00.txt
> >
> >
> >