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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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


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