[e2e] TCP, retransmissions, and ISPs with byte caps

[Sean Doran]

| A reasonable argument could be made, yes. I was thinking
| of cases where a weekly or monthly byte-count cap exists,
| and packet losses in the ISPs own network causes the
| enduser's TCP to generate repeat packets which are then
| counted against the monthly cap. Struck me as an
| interesting question for my students, but wanted to
| see if it had been done before.

Cool.  Ask your students:

        - how does one distinguish a packet lost due to congestion
          or corruption in the ISP from a packet lost elsewhere?
        - how does one detect the presence of multiple bottlenecks?
        - how can a good-willed ISP "credit" retransmissions it is 
          responsible for?
        - what should be done about retransmissions it is not responsible for?
        - is there a game-theoretical approach that can be taken when
          the rule is: "every packet/byte you transmit is deducted from
          a monthly token bucket, no exceptions", that maximizes goodput?
	- is the current TCP optimal for an environment in which
	  retransmissions triggered by something provably the ISP's
	  fault are re-credited into the token bucket, but other
	  retransmissons are not?

That should bend their brains for a while. :-)

(I made it easier by alluding to a partial solution to the third question,
in the two final questions; you could make it easier by talking about 
credit for packet drops, rather than retransmissions, but then you should
also make the final question harder by asking what a good-willed ISP should
do about senders who are significantly more aggressive than RFC2001).

	Sean.