[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello, Brian
Thank you for your kindly comments.

Your comment is right. 
If the notifications between L3Shim and TCP or ULP were needed, the proposed
way only should be performed at L3Shim layer.

Regards,
Taewan.

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
> Sent: Monday, July 18, 2005 3:34 PM
> To: marcelo bagnulo braun
> Cc: twyou@etri.re.kr; shim6
> Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
> 
> 
> marcelo bagnulo braun wrote:
> > 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.
> 
> Yes, since there is no particular reason in the shim6 model that all
> packets sharing shim6 state should belong to the same TCP connection,
> this would be quite wrong. The only way to do this properly is to add
> an API such that the shim can announce the change to the ULP; if the
> ULP happens to be TCP, it can decide to use this as a trigger. If the
> ULP happens to be UDP, it will ignore the information. And if both
> TCP and UDP are using the same shim6 state, they will behave differently.
> (And SCTP will of course be different again.)
> 
>      Brian
>