Re: [multipathtcp] High-level design decisions /architecture

[Yoshifumi Nishida <[e-mail]>]

Hello,

From: Scott Brim <[e-mail]>
Subject: Re: [multipathtcp] High-level design decisions /architecture
Date: Wed, 04 Nov 2009 20:05:47 -0800
Message-ID: <[e-mail]>

 > Yoshifumi Nishida allegedly wrote on 11/04/2009 12:19 PM:
 > >  > With per-subflow receive windows, you can use receive window tuning,
 > >  > too.
 > > 
 > > Well, that's an idea. Yes, I agree.
 > > I tend to agree that this can be a open issue now. But, I still have a naive question...
 > > 
 > > Compared to having a tweaky algorithm at receiver side, doing simple 
 > > negotiation during SYN exchange would be that difficult? (and probably we will
 > > also need to use 1 bit in Add Address option to specify primary path or etc, 
 > > but it's still simple.) 
 > > If we think about a small gudget like iphone, I guess simple receiving 
 > > algorithm might be preferable.
 > 
 > The problem with putting this in signaling is that you lose richness of
 > what you can do.  You need to have a few standard meanings for the bits
 > (or bit values) available to you, and so on.  Also, the particular
 > effect sought here is throttling traffic, which is exactly what receive
 > windows are good for.  If there is a need for anything else, maybe
 > signaling would be more appropriate.

Hmm. I understand your point.. but I have two opinions about this.
1: If a receiver has very sophisticated control algorithms (ACK streching or
   window size tweaking, etc), it can just refuse negotiation and control data 
   transfer by itself. 
   But, this does not prevent from having negotiation mechanism. 
   It still will be useful for simple receivers.

2: To do better control, I guess receiver will need to know sender's transfer 
   algorithm. Otherwise, things might get worse. 
   This will mean we need to have a signaling mechanism anyhow.

Thanks,
--
Yoshifumi Nishida
[e-mail]