Subject: Re: A question about RFC2960.

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 08:57:54 -0600

Ivan.Arias-Rodriguez,

On Fri, 05 Sep 2003, [email-masked] wrote:
> > 
> >    Note: Any DATA chunks that were sent to the address for which the
> >    T3-rtx timer expired but did not fit in one MTU (rule E3 above),
> >    should be marked for retransmission and sent as soon as cwnd allows
> >    XXXXXX                                  XXXXXXXXXXXXXXXXXXXXXXXXXXX
> >    (normally when a SACK arrives).
> >    
> > Because CWND allows on Destination B, they SHOULD be sent immediately.
> 
> 	But if the meaning is "sent as much as cwnd allows" and not "send only

THW interpretation, that is what it SAYS.

> 	a datagram now, and the rest later", the note doesn't make any sense,
> 	because you are ALWAYS able to have at least two datagrams in flight
> 	and thus you can always send at least 2*MTU bytes (little bit less in
> 	fact)...

Just the embarrasing correction in IG 2.7.

> 
> 	By the way, the note says "that were sent to the address for which the
> 	T3-rtx timer expired". I'm not sure if this is correct, since it takes
> 	for granted that you retransmit the chunks to the same address, which
> 	is wrong if you are not single-homed...

Well, they must have been sent to the address for which T3-rtx expired in the
first place, otherwise the timer would not have tolled for them...

--brian

> 	BR Iván Arias Rodríguez

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: [email-masked]
Date: Fri, 5 Sep 2003 17:53:26 +0300

> > 	I might be missing something, but I think that section 
> 6.3 has always
> > 	been quite clear in this respect. E3) says that you take all the
> > 	chunks that fit in a single packet and you retransmit 
> those packets.
> > 	Anywhere else it says that you can send a second (or 
> more) packet. It
> > 	explicitly says "in a single packet".
> > 
> > 	The Note later also leaves it clear: the chunks that 
> did not fit in
> > 	that single packet that you sent will be sent later. So 
> I suppose you
> > 	send only one.
> 
> Not later -- when cwnd allows.  Which in the multihomed case 
> is immediately.
> But in the single-homed case, typically after a SACK.

	I'm not sure that this was the original intention of E3). At least I have always understood it the other way...

	In any case, even if you are single home you are always able to send at least two packets, since you never send one MTU worth of user data in a single datagram...

> > 	I don't know how could you understand section 6.3.3 
> otherwise, but I
> > 	admit I could have been always missing something... :-/
> > 
> > > > 	In fact there is another problem. When you send a DATA 
> > > chunk you only
> > > > 	count as being on flight (MTU - IP Header Length - SCTP 
> > > Header Length
> > > > 	- DATA Chunk Header Length). So even if your cwnd is 
> > > set to 1*MTU you
> > > > 	can in theory have always at least two full packets in 
> > > flight, thanks
> > > > 	to what 2.7 in the Implementer's Guide says.
> > > > 
> > > > 	I think we have already spoken about this 
> issue, and the general
> > > > 	thought was that, as you don't really know how 
> > > "separate" are your
> > > > 	"different" paths (they might have much in common as 
> > > they come from
> > > > 	and go to the same physical destinations), you better 
> > > send a single
> > > > 	packet, since both paths might be sharing the congested 
> > > router...
> > > > 
> > > > 	But I'm with Wei here: as you won't normally send much 
> > > packets to the
> > > > 	secondary address (only those that were in flight when 
> > > T3 expired),
> > > > 	removing this rule of a single packet only after T3 
> > > expiration, can in
> > > > 	fact halve the recovery time after a T3 expiration... I 
> > > don't know
> > > > 	which can be the damage, though... :-/
> > > 
> > > What single packet rule?  There is no single packet rule 
> in the RFC.
> > 
> > 	It looks like a rule to me... See above.
> 
> Above where?  Where is the text that say I cannot use the 
> cwnd from the
> other desintation on a multi-homed connection?  I don't see 
> it anywhere.
> If anything the note says that you SHOULD send these TSNs as 
> soon as CWND
> allows, which for the other destination is immediately.

	I would like to hear more opinions on this, but what I understand is that you send only one packet.

	Otherwise, why explaining that you have to send one datagram? I think that if the idea was simply "send as much as you can" you wouldn't explicitly state that you have to send one datagram after the T3 expiration... that would only cause confusion...

> > > That was my point in highlighting 2.7.
> > 
> > 	But section 2.7 of the IG does not refer to the T3 
> expiration case. I
> > 	don't think it is related with section 6.3.3 of the 
> RFC. Section 6.3.3
> > 	implicitly (or quite explicitly I would say) states 
> that you don't
> > 	follow the cwnd/flight size rule and that you only send 
> one packet.
> 

	But if the meaning is "sent as much as cwnd allows" and not "send only a datagram now, and the rest later", the note doesn't make any sense, because you are ALWAYS able to have at least two datagrams in flight and thus you can always send at least 2*MTU bytes (little bit less in fact)...

	By the way, the note says "that were sent to the address for which the T3-rtx timer expired". I'm not sure if this is correct, since it takes for granted that you retransmit the chunks to the same address, which is wrong if you are not single-homed...

	BR Iván Arias Rodríguez

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 5 Sep 2003 09:10:28 -0600

Ivan.Arias-Rodriguez,

On Fri, 05 Sep 2003, [email-masked] wrote:

> 	Otherwise, why explaining that you have to send one datagram? I think
> 	that if the idea was simply "send as much as you can" you wouldn't
> 	explicitly state that you have to send one datagram after the T3
> 	expiration... that would only cause confusion...

No more confusion that neglecting to mention in the document that
one can slop over the MTU.  Thus the embarassment of IG 2.7.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 08 Sep 2003 07:57:20 -0500

>Just the embarrasing correction in IG 2.7.

Just a quick comment on the above while I read this
whole thread before responding to it.

... 2.7 was NOT a "embarrasing correction"... the "slop" over the congestion
window was ALWAYS in the document.. MANY implementations were
written this way... at least 4 that I can think of.. BUT some did not
bother to read the sentence so we decided to spell it out a bit 
clearer.. thats all.

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 08 Sep 2003 08:00:31 -0500

>one can slop over the MTU.  Thus the embarassment of IG 2.7.
The original RFC states:
"
   B) At any given time, the sender MUST NOT transmit new data to a
      given transport address if it has cwnd or more bytes of data
      outstanding to that transport address.
"

i.e.

if (flightsize > cwnd)
    no-more-sending

it does NOT state

if (flightsize >= cwnd)
   no-more-sending

Which is what some number .. 2 or 3 .. implementations were doing..

Now in reading the RFC (B above) I don't see how one could get the
second equation.. but some were.. this is why the clearification was put 
in... some
folks just needed to have it spelled out for them..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Sep 2003 13:11:57 -0600

Randall,

>       given transport address if it has cwnd or more bytes of data
                                          ^^^^^^^^^^^^ >= cwnd
>       outstanding to that transport address.

Don't you have that backwards?

--brian